[Hery]

Test is over

I've changed a few things in FSO and I wonder how the performance has changed. It is very subjective, hence I can't say too much now. Everything will be revealed later.

If you are interested in helping me, download the following three builds, test them and tell me what you think about it.
Test Builds
Test Builds Inferno
Obviously, missions with many ships, explosions, missiles, weapons, particles, etc should make a bigger difference in performance.
However, FPS is not the only important thing here. I'm interested in every aspect of FSO efficiency: game loading, mission loading, UI latency, etc.

All three builds are experimental and there may be some serious bugs. If you happen to encounter one, inform me about it, but if it's not critical continue testing the same build.

[The E]

Tested these by running them with mediavps and the "MassiveBattle2" mission.

Spoilered to not influence others:

Spoiler:

Build 1 performed on about the same level as a recent trunk SSE2 build. It seemed to introduce some crackling in the sound playback while in the menu, however-
Build 2 was prone to crashes. First crashed during mission load, then while playing the mission. (Just turning toward the action seems to trigger this)
Build 3, again, crashed on the first try. On the second, it didn't crash, and performance seemed to be about equal to Build 1.

[Hery]

Inferno builds uploaded.

The E: Thanks for your help.

[Fury]

Spoiler:

#1 - Didn't notice any difference to "normal" builds.
#2 - Crashes when tech room is opened.
#3 - Crashes when mission starts loading.

[Hery]

Thank you for testing.

All of these builds introduced new memory allocator that was able to allocate and deallocate memory in constant time ( O(1) allocator).

The biggest performance improvement was expected when FSO allocates memory many times (the best example are particle systems but they already have O(1) allocator). I wanted to check whether there are other objects in FSO which require fast allocation and deallocation.
Fortunately, there aren't and that means that the majority of FSO code can use the default allocator.

I provided you with three builds because power-of-two O(1) allocators usually waste about 30%-40% of memory and I was afraid that it may be a problem. That's why build 3 used O(1) allocator only for objects smaller than 1KiB and build 2 didn't use O(1) allocator at all. Unfortunately, there was a bug in code calling the default allocator, hence problems with build 2 and 3.

These tests proved that there is no need for general, power-of-two O(1) allocator. It is usefull only to allocate specific objects.