Jul 28 2016

TLDR - Part 4: Component filtering BLAZING fast with macros!

Made a huge optimization in the way Seagal filters list of entities that contains specific components!

Using the macro I’ve written two days ago as a base I now use bitflags instead of multiple for-loops and several, classB). I now just use simple bit-flag comparison as the macro auto-generates a unique bitflag for each component class, and the result is stunning!

I actually had to go back to my old test and change the number of entities from 10,000 to 100,000!!!

The critical part is the last test, taking 0.0469 seconds
The optimized code! 0.012 seconds! Thats 391% faster!!!

Note 1: Both test 2 and test 3 took 0.001 seconds when running 10,000 entities. That’s why I had to increase the number of entities.

Note 2: Test 2 now takes only 0.007 seconds with that huge amount of entities!

Note 3: Running identical test 3 with 100,000 entities on Edge gives an approx time of 0.049 seconds, even slower than my own old solution…

High fiving myself

Jul 22 2016

TLDR - Part 3

I’ve downloaded and tried a new exciting ECS-framework called Edge. The interesting thing about it is that it relies heavily on haxe macros to generate code at compile time that will remove of the costly runtime type checking.

I did a similar test to test number 3 in my TLDR - Part 2. Only the third test was interesting to me.

And look! It’s taking between 4 and 5 milliseconds here as well! That was surprising, I really though you had to try hard to be slower than my current implementation.

However, using macros seems super interesting. and I just got an idea on how I could use macros in seagal that might speed the matching up quite a bit!

May 08 2016

TLDR - Part 2

Starting designing my little game engine, I decided I wanted it to run on top of my existing ECS (Entity-Component-System) I made a few years back called Seagal. However - after started drawing a bit of system design on a piece of paper it became clear that I would require a HUGE deal of entities, components and component fetching. Looking at the code it became obvious that it was written for developer comfort and not the amount of speed that was required.

But that was just my gut feeling. What is better? Data! So I started writing a few performance tests:

My test suite consisted of

  • 10.000 entities
  • each having one TestComponent1 and one TestComponent2 attached
  • the tests are run on a windows build in release-mode.
  • on my stationary computer with an i5-4670 CPU @ 3.40 GHz, Win8.

So bootstraping the whole system, and adding the 10.000 entities with its components took 2 milliseconds. Not all to interesting, we will probably not add so many components during a game session. Rather during start-up.

My second test was to ask the system for an array of TestComponent1’s, disregarding which entity they belonged to. It took 2 ms for 10.000 entities.

In my third test I do three things: First I query a list of all entities that has both TestComponent1 AND TestComponent2 (in this test suite that means all of them). Then I iterate through all entities, requesting a reference to TestComponent1 and after that another reference to TestComponent2. That took 4 ms.

I was surprised to see the third test be only 4ms. I know I have a ton of possible improvements I can make. The look-up is not very efficient, and I do not cache the result so any subsequent calls would redo all that work even though nothing has changed.

Before I can go on I want to see if I can speed my ECS framework even more. Meaning that the next couple of posts will be about Seagal before continuing with TLDR!

Note to self: I found this existing ECS-framework for haxe that seems really interesting!