Add harmony-ecs and harmony-ecs-object benchmarks

[3mcd]

Added harmony-ecs, a little ECS that I plan on incorporating into Javelin as the component storage/query mechanism.

This PR adds two benchmarks: one for TypedArray component storage and one for plain objects, since the lib supports both. It also supports hybrid storage but would probably require some special benchmarks that don't exist in this repo yet.

I made a change to the start script to get the library to load correctly. That flag just tells node to resolve module paths like node file paths, enabling imports like import "./file" (without the .js extension). If you'd rather leave the flag out, let me know and I can see about exporting a single bundled entry-point.

Benchmarks were run on a Ryzen 5800x to get some nice fat numbers.

Thanks so much for your work on this repo!

[ooflorent]

You cut the grass right under my foot with this one! I was working on the same concept. The results are quite impressive. I'd like to wait a bit before merging this if you don't mind. I want to make sure that the API is stabilized.

One of the goals of this repository is also to showcase all “serious” ECS libraries out there. I'm not saying that harmony-ecs isn't serious but it is quite new, and I'd prefer to merge this once the javelin/harmony situation is settled.

Besides that, you achieved quite the novelty with this hybrid approach!

[3mcd]

Thank you for the kind words and for taking a look. I understand why you'd want to wait to merge.

I don't think the API is going to change very much, however. I also think the integration with Javelin is also not the best milestone to wait for to merge, since that will likely take months of work after harmony-ecs is "done" to update Javelin's network synchronization code, a feature not present in most libraries in this repo.

Do you have any thoughts for a better marker that harmony-ecs is ready for inclusion here? My initial thought is to get >80% code coverage and some more comprehensive docs written.

[ooflorent]

The main reason I want to wait is because of the extra maintenance cost. Updating every cases when I bump a library is time consuming (e.g. I wasn't able to update bitecs from 0.3.16 to 0.3.20 without getting a ton of errors). I would prefer to wait until the API is finalized.

I'm very curious, why did you rewrite the ECS module? What was wrong with Javelin's implementation? I understand the performance appeal from SoA but in my opinion it is only “smoke”. Until JS has proper typed objects (such as this https://github.com/rbuckton/proposal-struct), the DX is awful. How do you efficiently use a 4x4 matrix? Writing your own math lib to support a SoA version of this is overkill.

[3mcd]

It must be such a headache to maintain benchmarks while upgrading packages here. Props to you for doing that. And thanks for the link to the struct proposal. That's very interesting, and something I wished JS had as I dove into the internals of amethyst/flecs. Hopefully one day :)

The main appeal of TypedArrays/SoA to me for use in Javelin lies in the networking protocol. As I'm sure you know, it's a lot faster to copy TypedArrays into another ArrayBuffer than to use custom object encoders/decoders. Javelin also has a highly opinionated data model based entirely around objects. There's nothing wrong with it, it would just be both unnecessarily difficult and wasteful of my time to rewrite the existing data model while simultaneously "innovating", rather than starting at a blank slate.

So I made this library outside of Javelin to build a POC, and if the POC worked, I would publish it for wider use and get feedback from folks like you, the immediate Javelin community, and the JS ECS community at large. Only then would I finally integrate it into Javelin.

RE: ergonomics, it seems the community has decided that the performance tradeoffs are worth the poor DX with the popularity of BitECS. Most of the components I see my users writing are flat, storing things like ids, vectors, scalar values like health, damage, and entities. So I supposed 90% of components could be converted to TypedArray for modest performance gains in both iteration and network serialization.

I have some more thoughts here, but none of that is new to you since you've been working on the same concept.

[ooflorent]

And thanks for the link to the struct proposal. That's very interesting, and something I wished JS had as I dove into the internals of amethyst/flecs.

Another interesting proposal is https://github.com/syg/proposal-structs/. It got presented recently. Regarding other ECS implementations, bevy_ecs is worth exploring!

[3mcd]

@ooflorent I've updated this PR with a new version of the lib, which brought a couple small perf improvements and a single API change. I also enabled the tsconfig options you suggested and added some examples. It's good to go whenever you feel the time is right. Any changes made to the API from here should be additive.

[ooflorent]

I'm wondering if it wouldn't be better to remove harmony-ecs-object and then add a new suite to test interoperability with other libraries…

[3mcd]

That's a good idea! I'll go ahead and remove it under the assumption that we'll add a different set of tests.

We'd probably want to benchmark inserts of objects/mocked third-party objects in isolation, similar to the tests you have today. Then maybe a benchmark to iterate entities with both proprietary and third-party components, and utilize values from both in an addition operation or something.