Strange performance results with makr.js. Could someone explain the third test results?

README.md

Tests are located here:

• https://github.com/ooflorent/makrjs/blob/perf-internal/benchmark/internal-1.js
• https://github.com/ooflorent/makrjs/blob/perf-internal/benchmark/internal-2.js
• https://github.com/ooflorent/makrjs/blob/perf-internal/benchmark/internal-3.js

Execute the following command to run the test suite:

grunt benchmark:internal

output

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.

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.