Speeding up map load

[Grum]

Hello devs,

 

Ever since I (occasionally) started playing again, I've been annoyed by the ridiculously long map load times on my system. Turns out that this is mostly due to the combination of the update window showing the progress bar and slow graphics drivers (Ubuntu 11.04, the open source radeon drivers. I'm happy when I get 20 FPS). Removing the use of the update window when changing maps reduces the load time by about a factor of 10. Below are the map load times in a very scientific benchmark, where I log in on the Whitestone map, take a boat to DP, return, and repeat the process. All times are wall clock times in seconds:

                WS    DP    WS    DP    WS
Original:        3.82  0.69  3.71  0.68  3.70
No progress bar: 0.55  0.08  0.36  0.05  0.35
Other:           0.35  0.04  0.15  0.02  0.14

The first column is of course slow, because none of the caches have been initialized yet, and everything has to be loaded from disk, which is why I've included the two round trips to DP.

 

In the final row I've also included a bunch of other optimizations I've made, which include:

* Keeping the object and texture caches sorted, so that we can use a binary search instead of looping over the entire cache to find an object.

* Same for the list of harvestable and entrable objects.

* Keeping a counter on where to insert the next 2D/3D object corresponding object list, instead of (again) looping over the list to find the next empty slot.

* Getting rid of the use of get_string_occurance() when parsing 2d0 files. This is a glorified strstr() which is quite slow. Instead of searching for field names in the file data (for every field), simply parse the file and process the keys we recognize.

 

The total patch also contains a few cleanups and is rather large (+1139, -1402), so I've refrained from posting it here, but given that the largest map I could easily reach (Whitestone) now loads almost instantaneously on my laptop, I wonder if it's worth the trouble of keeping the progress bar.

 

So what do you guys think? Should we just remove the load window for map changes? Is there any interest in merging this?

[Learner]

Hello devs,

 

Ever since I (occasionally) started playing again, I've been annoyed by the ridiculously long map load times on my system. Turns out that this is mostly due to the combination of the update window showing the progress bar and slow graphics drivers (Ubuntu 11.04, the open source radeon drivers. I'm happy when I get 20 FPS). Removing the use of the update window when changing maps reduces the load time by about a factor of 10. Below are the map load times in a very scientific benchmark, where I log in on the Whitestone map, take a boat to DP, return, and repeat the process. All times are wall clock times in seconds:

            	WS    DP    WS    DP    WS
Original:        3.82  0.69  3.71  0.68  3.70
No progress bar: 0.55  0.08  0.36  0.05  0.35
Other:       	0.35  0.04  0.15  0.02  0.14

The first column is of course slow, because none of the caches have been initialized yet, and everything has to be loaded from disk, which is why I've included the two round trips to DP.

 

In the final row I've also included a bunch of other optimizations I've made, which include:

* Keeping the object and texture caches sorted, so that we can use a binary search instead of looping over the entire cache to find an object.

* Same for the list of harvestable and entrable objects.

* Keeping a counter on where to insert the next 2D/3D object corresponding object list, instead of (again) looping over the list to find the next empty slot.

* Getting rid of the use of get_string_occurance() when parsing 2d0 files. This is a glorified strstr() which is quite slow. Instead of searching for field names in the file data (for every field), simply parse the file and process the keys we recognize.

 

The total patch also contains a few cleanups and is rather large (+1139, -1402), so I've refrained from posting it here, but given that the largest map I could easily reach (Whitestone) now loads almost instantaneously on my laptop, I wonder if it's worth the trouble of keeping the progress bar.

 

So what do you guys think? Should we just remove the load window for map changes? Is there any interest in merging this?

Since some systems are faster and slower, I suggest you at least through up a "Loading..." text if it doesn't slow down the loading like the progress bar does. Or have the progress bar only updated at a couple steps?

[Grum]

Since some systems are faster and slower, I suggest you at least through up a "Loading..." text if it doesn't slow down the loading like the progress bar does. Or have the progress bar only updated at a couple steps?

Fair enough.

Currently the progress bar is updated every 100 objects. Every update of the bar causes a repaint, which apparently on my system brings it to its knees.

 

I'll have a look to see what happens if I don't update the progress bar when loading individual objects, just on the major steps (Loading tiles, Loading 3d objects, etc.)

[bkc56]

Currently the progress bar is updated every 100 objects.

I don't know how many total objects we're talking about, but updating the bar 5-10 times total for the map rather than a more continuous smooth bar would still be adequate to give people an idea of how it's going without doing so many individual updates.

[Grum]

Currently the progress bar is updated every 100 objects.

I don't know how many total objects we're talking about,

Currently, for the WS map there are 12069 3D objects, and 8632 2D objects, resulting in over 200 updates to the progress bar (though I just found out that in current git, the bar is only updated every 250 objects).

but updating the bar 5-10 times total for the map rather than a more continuous smooth bar would still be adequate to give people an idea of how it's going without doing so many individual updates.

So that's what I did, only updating on "Showing map", "Loading 3D objects", "Loading 2d objects", "Loading lights", "Loading particles", "Building sectors", and "Done". This slows things down by a small amount, but not overly so:

          WS    DP    WS    DP    WS
Non-smooth 0.39  0.11  0.19  0.11  0.18

Those are delays I can live with.

[korrode]

So, you've reduced the loading time of the Whitestone map by like 90%, and hugely reduced loading times of other maps too. Fucking epic. Nice work.

[Raz]

So, you've reduced the loading time of the Whitestone map by like 90%, and hugely reduced loading times of other maps too. Fucking epic. Nice work.

Thanks for putting it so succinctly Korrode - I thought thats what it was!

 

Great work - many thanks!

[Grum]

So, you've reduced the loading time of the Whitestone map by like 90%, and hugely reduced loading times of other maps too. Fucking epic. Nice work.

Thanks for putting it so succinctly Korrode - I thought thats what it was!

 

Great work - many thanks!

Thanks, but please note that you will only get a 90% speedup when your graphics card or the drivers suck. For normal systems the speedup is probably closer to a factor 2-3.

 

I actually managed to speed it up even further, the WS map now usually loads in 0.07s on my system when I disable the update window entirely (obviously not on the first load, then it's more like 0.25s).

[Entropy]

That sounds like a very good speed improvement, will test it alter. but next time, PLEASE ask before commiting such critical code, especially so close to the update.. We'll have to roll back the changes for now, except for the bar thingy.

[hussam]

On a relatively faster system, the 'loading' progress bar isn't so smooth anymore. On entering whitestone it gets stuck for a tiny fraction of a second then finishes. The speed improvement is there but it's less smooth when the progress bar is only two steps.

Edited June 9, 2011 by hussam

[Entropy]

Anyway, we rolled back all the chances, it is way too experimental for now. After the updated, please commit it with some #ifdef guards.

[Entropy]

BTW Grum, by any chance, do you have a SSD on your computer, rather than a HDD?

[Alberich]

Well most of main commit was cosmetics, maybe make a branch and commit your changes in small perspicuous pieces.

 

I think the changes are not as critical as they might look at first glance. And the results would be a really addition to Xaphs speedups.

[Entropy]

Any code that alters a main feature (such as the way the maps are loaded, especially by replacing and reordering stuff) is critical. Besides, Bluap said there were some errors with the string functions. Anyway, the right way to do it is with some #defines, but after the update. Or as a patch.

[Grum]

Apologies, I did not realize an update was about to happen.

 

Anyway, the string thingy wasn't supposed to go in, so reverting that is entirely reasonable. But there are also some issues with NEW_TEXTURES, so I'll create a branch for this. Still getting used to this new-fangled git thingy. Huge improvement over CVS though.

 

And no, no SSD.

[Entropy]

Well, I have a good video card, that is capable of MANY FPSs, and for me loading WS, cached or not cached takes a while (about 5 seconds or so, not timed). I find it very hard to believe that just updating the bar will cause such a huge delay, so perhaps there is something else involved? Or maybe you have a really fast HDD, or the Linux caching is much superior to the one used on Windows?

[Grum]

I do have a rather fast HDD, but I did get from ~4s to ~0.5s by just disabling the update window, with no other changes. Note that normally in game I get 25 FPS max. Of course this is slower then when we just update the progress bar, but the 200+ updates to this bar @25 FPS translates to 8s. So for me, the bar is really an issue.

 

EDIT: about caching, I'd be surprised if Linux is that superior. I have a lot of RAM (4GB), so it's possible that the system is able to hold the pages in memory while I'm testing.

Edited June 10, 2011 by Grum

[Entropy]

You have 25fps during the game, but that's a lot of rendering. With a semi empty screen, you should have at least 200 fps..

Where exactly is the code you have to modify the number of objects required for one status bar update?

[bkc56]

Could we add a simple switch (like a command line option) to the next RC to get a wider base of testing? It could be really basic and simply turn off the bar (no updates). The feedback would help decide what to do, and the switch would be removed for the final release.

 

Even simpler would be to just disable the progress bar for the next RC and ask for feedback on map load times with RC2 vs RC3. Again, just a short-term test to get a wider base of feedback.

 

At least then we'd know if it helps everyone in varying amounts, or if it's only helping certain configurations.

[Entropy]

BTW, on my reaaaaaaaally crappy netbook (Atom 1.3ghz, Intel 500GMA) White Stone loads much faster than on my desktop. This is because it has a SSD.

[Grum]

so I'll create a branch for this.

Which apparently I can't. Do I need permission or something?

remote: -Info-          The branch 'refs/heads/map-loading' is new...
remote: -Info-          The user is: 'grum'
remote: -Info-          The user belongs to the following groups:
remote: -Info-          'grum elc'
remote: -Deny-          There are no more rules to check.  Denying access

You have 25fps during the game, but that's a lot of rendering. With a semi empty screen, you should have at least 200 fps..

True enough. Note that 200FPS still corresponds to an extra second of delay, though.

Where exactly is the code you have to modify the number of objects required for one status bar update?

io/map_io.c, check the calls to update_func

BTW, on my reaaaaaaaally crappy netbook (Atom 1.3ghz, Intel 500GMA) White Stone loads much faster than on my desktop. This is because it has a SSD.

I can imagine it could take some time on a fully loaded system with a crappy HD, but not seconds. I see *some* delay due to I/O, especially on first load, but as said, I can load the WS map and all the objects and textures on it in 0.5 second from a fresh login. And the second time you enter a map you should not hit the HD at all, no?

[Entropy]

I don't think you should create a branch just for that, because they are relatively minor changes. #ifdef should probably be a better idea, but please wait until after the update (should be ina week or so hopefully).

As for why it takes so long, I have no idea, my HDD is not that crappy, but not the fastest either. And I guess windows doesn't cache everything, even though I have 3GB of ram.

[Grum]

I have just pushed the changes into master, with the relevant bits protected by #ifdef FASTER_MAP_LOAD.

[Entropy]

Excellent.

Did anyone try them yet?

[hussam]

I am. The loading screen progress bar is a bit choppy now (used to be a smooth progress bar) but there is a slight speedup in loading maps like White Stone.

I'll report any crashes if they happen.