Build 434: Startup performance?

skyjakeskyjake
edited 2012 Mar 19 in General
Today's build 434 introduces a set of optimizations that should improve the startup performance of the engine. I have two questions for you guys:

1) How much faster is it? (Seconds, percentage, etc. numbers appreciated)

2) Can you spot any regressions or other new resource related bugs? Optimizations are tricky because they often involve radical changes in the logic, and the end result may not exactly match the original behavior.

PS. The red flag on the Ubuntu packages should be benign: the install script is trying to do a binary strip on the launch script, which is a shell script and obviously cannot be stripped.

Comments

  • JCAJCA
    Well, it takes about 7 seconds to start first level without models and 11 seconds with models. Build 425 took 9 seconds without models and 23 seconds with models.
  • VermilVermil
    About 4 seconds with no add-ons loaded in build 434 vs 7 seconds in 430.

    Most of that improvement came from the final stage of engine startup; 3.34 seconds in 430 vs a stunning 0.72 seconds in 434.

    Most other areas of engine startup in 434 were comparable to 430 (.4 second less here, .4 second more there etc).
  • garygary
    It is much faster. Game startup (the final part of loading the menu) takes about 1.5 seconds instead of 10 to 12 seconds. The amount of time it takes from clicking 'play' to displaying the menu is about 4 seconds. Keep it up. Very good. This makes me happy. Perhaps Lightning Hunter will also be pretty pleased. I also like that instead of individual segments of the loading wheel being filled in, it now displays the progress of loading more accurately since it is doing so pixel by pixel, like filling up a glass of water.
  • MiltenMilten
    I have the same experiences as Gary. The startup from the engine itself (with addons) is a lot faster, like only a few seconds.
    For map loading it depends on the level itself, TNT map 31 (warping from map 01), took me 7 seconds to load with full addons.
  • Lightning HunterLightning Hunter
    Sorry it took me so long to respond to this thread. Startup time for me when using the JDRP still takes a long time. About 35 seconds, as opposed to 5 seconds of version 364. I just tested build 439. What's odd is that version 364 takes just as long to load with all the addons as this version does with NO addons.

    What could possibly account for this long startup time for me? Why did 364 load so fast, and every version after that so slow?
  • garygary
    It must be lack of optimization.
  • skyjakeskyjake
    Lightning Hunter wrote:
    I just tested build 439.
    Build 439 does not have these optimizations: it's an updated stable release of 1.9.7. Build 438 is the latest unstable build of 1.9.8.

    We realize the build repository isn't very clear on the difference between the builds at the moment...
  • Lightning HunterLightning Hunter
    Ok, I just tested build 442. Indeed, it does start much faster! It takes about 8-10 seconds. Although this is not quite as fast as build 364, it is much better than waiting 40 seconds! Good job.

    If the detail textures would be fixed (Dani's messed up detail textures), then I'd finally consider the build worthy of replacing 364.

    By the way, I noticed that the map name is back in the automap, but is hidden behind the statusbar if you have it enabled... Can this be fixed?
  • DaniJDaniJ
    Lightning Hunter wrote:
    If the detail textures would be fixed (Dani's messed up detail textures), then I'd finally consider the build worthy of replacing 364.
    The problem there is the textures themselves. Those were not authored 'correctly' in that they did not make full use of the whole contrast range. For Doomsday 1.9.7 I implemented an algorithm which automatically boosts the contrast and shifts the mid point of deficient detail textures to ensure that they do not adversely affect lighting (there are a lot of very poorly made textures out there...). What is missing is that this boost to the image contrast is not also factored in to the detail strength blend factor.
  • Lightning HunterLightning Hunter
    DaniJ wrote:
    The problem there is the textures themselves. Those were not authored 'correctly' in that they did not make full use of the whole contrast range. For Doomsday 1.9.7 I implemented an algorithm which automatically boosts the contrast and shifts the mid point of deficient detail textures to ensure that they do not adversely affect lighting (there are a lot of very poorly made textures out there...). What is missing is that this boost to the image contrast is not also factored in to the detail strength blend factor.

    Assume that I know nothing about anything you just said. :P

    Is this something that will be "fixed" in Doomsday then, or does the detail pack need to be modified since it no longer works?
  • DaniJDaniJ
    No the pack does not need to be changed. This is something which will be addressed by adjusting the renderer's detail texture blending factor as mentioned in my previous post.
  • VermilVermil
    Put simply, the existing Doom detail textures were not made quite correctly in one area. But it is something that Doomsday can compensate for and will do in future.
Sign In or Register to comment.

© Vanilla Keystone Theme 2024