Optimization: Dividing memory usage by almost 3

[xavierjs]

Hi

Thank you for considering my PR.

This is an implementation of this improvement submitted and merged in Maplibre geojson-vt fork: maplibre/geojson-vt#88

All the tests succeed.

[xavierjs]

@mourner Thank you for considering this PR :). It really improves memory usage

[xavierjs]

@astojilj @ibesora @endanke

[mourner]

@xavierjs thank you for the contribution, this does look very promising! I'll investigate. Worth checking whether the additional nesting can introduce overhead in some situations — maybe we could get away with some other way to store and pass around metrics info that's even less obtrusive. Also, we should benchmark extensively to see how this affects index generation times — there must be some overhead because as far as I remember, creating a typed array is more expensive in terms of CPU time than just an empty array (which is heavily optimized in v8).

[xavierjs]

Hi @mourner

I ran the Maplibre geojson-vt fork benchmarks measuring the duration, and indeed there is a slight performance degradation in the benchmarks (between 5 and 10%) if we set the conversion threshold to -1 (i.e. we always convert to typed array): https://github.com/xavierjs/geojson-vt_mapbox/blob/636a214435167fd25d8ec4db672a0f4918a9b11d/src/feature.js#L40

This is why I set a conversion threshold to 64. With this value there is almost no performance degradation in the benchmarks (less than 3%), but the memory savings are still huge.

[xavierjs]

Hi @mourner,

Just wanted to follow up on this PR when you have a moment.
Let me know if you have any questions or need anything from me.

Thank you!

[xavierjs]

Good morning! Just a gentle ping to @mourner @astojilj @ibesora @endanke
Whenever you have a moment, I’d love your feedback on this PR. Thanks so much!

[mourner]

@xavierjs hey, thanks for the reminders — we're looking into this but don't expect us to land it soon, we'll have to explore this extra carefully. There are some things here I'm hesitating about:

• While replacing numeric arrays with Float64Array instances does reduce overall memory in the benchmark that forces GC before measurement, the added GC pressure in a real-world app might be a serious problem — after the PR, geojson-vt would overall allocate more (as it builds those arrays first) and GC more.
• We need to measure the impact on indexing run time, not just memory heap size after GC.
• I'm not confident custom properties on array obects (or typed arrays) are actually a problem in this case (the bench doesn't measure this), and additional object nesting adds overhead — need to double-check.

I'll let you know after exploring this.