[m!m]

I need some help with testing some changed I made to the shader handling of FSO which should improve performance a bit. I'm pretty confident that these build don't change the behavior of the engine but some additional testing would be great.

Download (this includes a trunk build and the changed build to be able to do accurate performance testing)
The source code can be found here: https://github.com/asarium/fs2open.github.com/tree/shaders

I did some performance testing myself which resulted in this image:
(Blue is trunk, green is with refactoring)

These graphs were made using the new -profile_write_file which both of these builds support.

Thanks for your help!

[Aardwolf]

I'm not able to help test at this time, but seeing boost::unordered_map has got my attention, as I've got a fair amount of experience trying to optimize map add/lookup/erase operations in my own game engine.

What are you trying to accomplish with boost::unordered_maps? Are you replacing std::map or some /SCP equivalent? Or are you trying to speed something up that previously didn't use maps?

In my experience, dynamic memory allocation is the enemy. As far as adding elements to the map, boost::unordered_map—with its underlying vector implementation and the ability to call rehash in advance to tell it how much capacity you expect to use—is superior to std::map—which seems to allocate additional memory every time you add something. But if you're only adding to it when you load the shaders and the big concern is lookups, then it probably doesn't make as much difference.

[m!m]

The map is only initialized when the shader is initially loaded but there is still a difference between std::map and a hash map (which is what boost::unordered_map implements).
std::map implements a binary tree which has a O(log(n)) complexity for one lookup. If the hashing is done correctly a hash map has a complexity of O(1) which is way better than what std::map provides which is why I used that.

[Aardwolf]

RE: O(log(n)) vs O(1): Yeah I knew that, and assumed that if what you've changed was a switch from std::map (or equivalent) to boost::unordered_map that that would have been the reason for it. But I didn't know for sure that that's what you'd done. I mean sure I could've looked at the diffs or something, but I didn't.

[m!m]

Current trunk uses a vector to store the uniforms and does a sequential search to find the right one which caused that particular function to use ~15% of our CPU time while I was profiling (it's probably less in a release build but still quite a bit). SCP currently uses hash map implementations supplied by the various compiler vendors but at least the performance of the MS version is horrible. boost::unordered_map even outperforms current C++11 implementations so I decided to give it a go and it obviously worked.

[Aardwolf]

What about between t=100 and t=125 on the graph?

[m!m]

I generated the graph with the WiH intro cutscene and at that point there are a lot of objects on the screen which is where the refactoring will improve the performance the most as each object requires quite a lot of uniform setting.

[Aardwolf]

Oh, the Y axis is FPS, not ms... derp.