VZNCore ECS / open source engine / measured against jecs 0.11.0

Benchmarks

I wrote my own entity component system, open sourced the engine, and I measure it against jecs, the fastest open ECS on Roblox, every time I change it. On the status flags a combat game churns thousands of times a second, mine is 1.35x faster. On queries the two are close. jecs is ahead on spawning, and that row is here too. Every row of the last run is below: faster on 2, even on 5, slower on 6.

Get the engine on GitHubAbout me

Every row

Sep 20, 2026 / 9 runs
Faster: won every runEven: within 10 percent, or the winner changes between runsSlower: lost every run by more than 10 percentBars are log scale. The centre line is jecs.
Toggle a marker, stored sparseThe same stun or buff flag in the storage mode I wrote for exactly this.5,000 entities, add then remove
1.35xFaster / won 9 of 90.66 us vs 0.95 us
5 structural changes in one scopeA heavy ability landing: several states set and cleared together.5,000 entities, 10 moves each
1.10xFaster / won 9 of 95.07 us vs 5.55 us
Query 2 components across every entityWhat a movement or health system does every frame.10,000 entities, all match
0.84xEven / won 4 of 90.93 ms vs 0.95 ms
Query 4 components, a quarter matchA narrower system picking its entities out of a mixed world.10,000 entities, about 2,500 match
0.92xEven / won 2 of 90.20 ms vs 0.19 ms
Cached query in a crowded worldA hot system staying fast while the rest of the game grows around it.200 matches among 250 unrelated archetypes
0.94xEven / won 1 of 913.01 us vs 12.94 us
2 structural changes in one scopeA hit that applies two effects at once.5,000 entities, 4 moves each
0.94xEven / won 1 of 92.31 us vs 2.15 us
3 structural changes in one scopeA hit that applies three.5,000 entities, 6 moves each
0.96xEven / won 0 of 93.36 us vs 3.19 us
Spawn an entity and add 2 componentsPaid once per enemy, projectile or pickup, when it is created.10,000 entities per pass
0.50xSlower / won 0 of 91.75 us vs 0.77 us
Same spawn, components added one call at a timeThe slower of my two spawn paths against jecs at its fastest.10,000 entities per pass
0.48xSlower / won 0 of 91.55 us vs 0.77 us
Same spawn, components added in one bulk callMy bulk path is the slowest of the three. It exists for readability, not speed.10,000 entities per pass
0.28xSlower / won 0 of 92.63 us vs 0.77 us
Add and remove a data componentAttaching and clearing a component that carries data, such as a timed effect.5,000 entities, 2 archetype moves each
0.81xSlower / won 0 of 91.27 us vs 0.99 us
Toggle a marker, stored the ordinary wayA stun or a buff flag kept in the archetype table.5,000 entities, add then remove
0.69xSlower / won 0 of 91.27 us vs 0.95 us
Walk every child of a parentInventory items on a player, minions on a boss.5,000 children
0.74xSlower / won 0 of 91.03 ms vs 0.73 ms

What that means in a game

Read honestly
Combat

Status flags are 1.35x faster

Stuns, buffs, cooldown flags: a fighting game adds and removes thousands of these a second. I wrote a sparse storage mode for exactly that, and it won all 9 runs. Stored the ordinary way instead, the same flag is slower than jecs, which is why the mode exists.

Every frame

Queries run close to jecs

Iterating entities is what a game does sixty times a second, and it is where a slow ECS costs you frame rate. On the three query workloads jecs leads by 6 to 16 percent on the median, and the winner changes between runs. That is the same class of engine, not a gap a player would ever see.

Once per entity

jecs spawns about twice as fast

Creating an entity and moving it between tables is where jecs is clearly ahead, and I have not closed that gap. In absolute terms it is 1.75 us against 0.77 us per entity, paid once when an enemy or a projectile is created, not every frame.

Why write my own

jecs is a library. This is a framework.

jecs is an excellent engine and it does one job: storing and querying entities. A game needs a lot more than that before anything appears on screen, and every studio that adopts jecs ends up writing the rest themselves.

VZNCore is the rest, with an engine of the same class underneath: replication that only sends what changed, a scheduler, player data, server-side validation of every client request, debug lints that name the entity that went wrong, and an inspector for looking inside a running world. Owning the engine is what lets all of that be designed together instead of bolted on.

The engine is open source. The VZNCore template on my GitHub is MIT licensed and carries the test suite, examples and a benchmark harness you can run yourself. The framework around it is private: it is not sold, and it ships inside client games and nowhere else. I have been working on it for months and I expect to keep working on it for years. More about me and how I work.

Method7 timed passes per run after 2 warm-ups, median reported
Runs9, each reported row is the median across them
Baselinejecs 0.11.0, its own fastest path in every scenario
RuntimeLune 0.10.5, both engines in the same process on the same machine
Same workidentical entity counts, component shapes and iteration counts on both
Reproducethe public template ships a smaller harness pinned to an older jecs; these rows are the full suite against the current release, which is the harder comparison
Ask me about it vznzach on DiscordEngine on GitHubSee what it runs