Skip to content

Instantly share code, notes, and snippets.

@ooflorent
Last active December 23, 2015 23:49
Show Gist options
  • Save ooflorent/6712063 to your computer and use it in GitHub Desktop.
Save ooflorent/6712063 to your computer and use it in GitHub Desktop.
Strange performance results with makr.js. Could someone explain the third test results?
Running "benchmark:internal" (benchmark) task
Running suite Remove 200 entities from 3 systems (no loopStart()) [benchmark/internal-1.js]...
>> clear() x 342,370 ops/sec ±3.51% (81 runs sampled)
>> kill() x 392,034 ops/sec ±5.49% (73 runs sampled)
Fastest test is kill() at 1.15x faster than clear()
Running suite Remove 200 entities from 3 systems (only loopStart()) [benchmark/internal-2.js]...
>> loopStart() after clear() x 14,650,174 ops/sec ±1.14% (92 runs sampled)
>> loopStart() after kill() x 14,177,501 ops/sec ±1.31% (91 runs sampled)
Fastest test is loopStart() after clear() at 1.03x faster than loopStart() after kill()
Running suite Remove 200 entities from 3 systems (full) [benchmark/internal-3.js]...
>> clear() then loopStart() x 67,252 ops/sec ±1.34% (92 runs sampled)
>> kill() then loopStart() x 386,155 ops/sec ±4.71% (74 runs sampled)
Fastest test is kill() then loopStart() at 5.7x faster than clear() then loopStart()
Done, without errors.
@mraleph
Copy link

mraleph commented Oct 23, 2013

Well I have no idea what makr is or what it does, so everything below comes from just quickly reading through the code.

Lets recall how harness runs benchmarks:

  1. it does whatever body of the setup tells it to do;
  2. it does many iterations of whatever fn tells it to do and measures how long they took.
  3. it repeats steps 1&2 multiple times (each repetition is called sample).

Notice this one setup - many fn organization.

Now lets quickly looks through the code for kill. Once you do entity.kill, it gets into world._removed queue. This queue is processed when you do loopStart and all entities are actually killed via _removeEntity. _removeEntity sets entity's _alive to false and does nothing for non-live entities.

This means that in your third benchmark in kill case only the first execution of fn body in a sample does any heavy work because on all subsequent executions entities are already killed.

Hence the speed increase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment