ecx.ds.* as separate library?

[PDeveloper]

I'm sniffing your codebase because I want to find where the speed comes from : ) The ecx.ds.* package looks very useful for general use, and was wondering if there are any plans on releasing it as a separate ds package?

[eliasku]

@PDeveloper,

And review this one https://github.com/eliasku/hotmem I have thoughts on including ecx-ds to hotmem library. What do you think?

BR, Ilya

[PDeveloper]

I saw that! I think it would make sense to have hotmem live under a ecx-ds name, since it also deals with data, other way around feels a bit awkward in my opinion.

But all of these would be great to have! I'll see how far I get, I have a few more refactoring ideas that rely on the base haxe data structures, since the less dependencies, the better, but I'll test to see where I can get using these ones.

[eliasku]

@PDeveloper In my opinion if hotmem library is more general library and application is not related to ECS, then why we should name it as ecx-ds? For example, I use hotmem library for low-level rendering library. I could use it for server logic, utilities or something else. And other could use it as not-ecx part for doing something else.

Another question is: should I move specific CArray / CBitArray / CIntArray to hotmem or not. I think I should move it to more general library because I don't want to duplicate small optimised target-specific.

[PDeveloper]

True, I was more basing it around the ds part, since hotmem sounds more specific than something-ds . If grouping data structures, those definitely fit in the box I think!

It might be worth checking out: https://github.com/polygonal/ds

[eliasku]

hotmem provides global heap for some managed targets. I think it could be better to leave hotmem separated and not include it into the core of ecx.

ecx.ds provides generic collections for all managed targets, it could be slower than hotmem, but not wires up to one global heap. So ecx.ds is mostly fast implementation for simple and primitive collections across all supported targets. So from moment ecx.ds has been fully defined as a library - we could decompose the collections to separated library and add on top of them another not overwhelmed primitive collections not just for ecx.

polygonal.ds contains complex data-structures, otherwise ecx.ds provides simple primitives , which could be optimized better across all supported targets

[PDeveloper]

Okay nice. ecx.ds will remain internal to ecx?

[eliasku]

@PDeveloper In general I will decompose ecx.ds to external library. When I will have free time to do it...

[PDeveloper]

Gotcha :D Sounds good, thanks for this!