Cache

[MioQuispe]

This caches entities by their mask

[coveralls]

Coverage remained the same at 100.0% when pulling 84e2166 on MioQuispe:cache into 1cbe5bc on makrjs:master.

[ooflorent]

Do not add anything to the entity.
Instead create an Int32Array to store indexes like _entityMask.

[MioQuispe]

Good idea.

[MioQuispe]

Fyi, I tried preallocating an array based on the amount of entities the query will return. The speedup was roughly 2-3x for 100k entities 50k returned

[ooflorent]

Can you rebase on master?
I've fixed a bug on Entity#destroy

[MioQuispe]

Sure thing.

[ooflorent]

Can be optimized:

this._entityCache = FastMap()
this._entityCache[0] = []

See https://gist.github.com/ooflorent/c58c9a0f08923973a5e3

[MioQuispe]

So do you suggest I add fast.js to the project and require it?

[ooflorent]

Yes. Next to utils.js.

[MioQuispe]

Getting:

/home/user/Projects/mq_makr/makr/lib/fast.js:10
  ForceEfficientMap.prototype = self
  ^^^^^^^^^^^^^^^^^
SyntaxError: Unexpected identifier

[ooflorent]

Fixed on the gist.

[MioQuispe]

Oh, wow didn't notice the missing brackets

[ooflorent]

Well let's finish the PR, add some tests to ensure there a no duplicates and we should be good

[MioQuispe]

I've added several tests which seem to confirm it's working correctly. But I have something I want to still add to it which would effectively get around the .push() problem. I predict this will have a very big impact on the performance.

[MioQuispe]

Initial numbers (All tests pass, including the new ones):

                  EntityManager
  57,264,548 op/s » query on 1000 entities with 1 component (500 matches)
  35,554,763 op/s » query on 1000 entities with 3 components (84 matches)
  10,677,708 op/s » query on 1000 entities with 10 components (1 match)

                  EntityManager
  59,946,961 op/s » query on 10000 entities with 1 component (~5000 matches)
  32,865,792 op/s » query on 10000 entities with 3 components (~840 matches)
   8,758,721 op/s » query on 10000 entities with 10 components (~4 matches)

                  EntityManager
  58,063,592 op/s » query on 100000 entities with 1 component (~50000 matches)
  32,834,461 op/s » query on 100000 entities with 3 components (~8400 matches)
   8,797,725 op/s » query on 100000 entities with 10 components (~40 matches)

As you see, it will be independent of the amount of entities.
So what's going on? The query results are cached.
Whenever an entity is created/destroyed/has a component added/removed
the respective query result caches are set as invalid and get rebuilt the next time query is called with their mask. So no, these numbers aren't 100% realistic as each affected query cache will have to be rebuilt whenever an entity is modified. The good thing is (apart from the crazy speeds when the query cache is used) this should mean much less work for the garbage collector and we aren't really using any extra memory since these arrays would be created anyway each time a query is performed. Unfortunately this adds quite a bit of overhead for modifying entities:

Before:
168,066,626 op/s » #destroy
81,404,501 op/s » #add
84,897,373 op/s » #remove
1,533,740 op/s » #create

After:
34,618,246 op/s » #destroy
2,773,040 op/s » #add
3,422,823 op/s » #remove
880,812 op/s » #create

This is something I'd like to fix by scheduling the cache invalidations for the next query somehow. I'd like to see the numbers back to the old ones ;). Let me know what you think. All the other numbers stayed the same btw.

[eranimo]

Can this be merged?

[ooflorent]

@eranimo I don't think so. I'm not fully satisfied by this change. While the performance improvement is huge for query, there is a significant overhead for entity manipulation methods.