Atlaslog / Field Notes / deck.gl visualization
Field note · deck.gl visualization
1.2 million GPS rows crash the tab with an array buffer error
Quick answer
Parsing 1.2 million CSV rows into object arrays costs 400 MB before any rendering, and deck.gl keeps the previous copy for diffing, so the peak approaches 2.4 GB. The page dies inside TripsLayer.initializeState with a Float32Array allocation failure.
Symptom
- Uncaught RangeError: Array buffer allocation failed at new Float32Array, thrown from TripsLayer.initializeState (trips-layer.js:88).
- performance.memory.usedJSHeapSize reaches 2.4 GB and does not fall after GC, so the data is retained.
- The tab title becomes 'Page unresponsive' and the canvas goes white.
Checklist
- Log record count and usedJSHeapSize before and after parsing.
- Cut to 100k rows to confirm the crash is a scale problem rather than one bad record.
- Check whether data is an object array from d3.csv or papaparse instead of typed arrays.
- Inspect getPath for per-point temporary array creation.
Fix
Feed binary attributes (Float32Array positions and timestamps) through data: { length, attributes: { getPosition: { value, size: 2 } } }, load by tile or time window on moveend, and pre-build flat path arrays for TripsLayer.
Code
Uncaught RangeError: Array buffer allocation failed
at new Float32Array (<anonymous>)
at TripsLayer.initializeState (trips-layer.js:88)console.log('记录数', data.length);
console.log('堆内存 MB', (performance.memory.usedJSHeapSize / 1048576).toFixed(1));
Watch out
- Keeping the original CSV object array for tooltips doubles retained memory and defeats the binary path.
- Rendering all 1.2 million rows in one TripsLayer and only lowering trailLength does not reduce the allocation.
English edition written for Atlaslog from the original Chinese field note. Code is unchanged and runs as-is.
Atlaslog (2026). 1.2 million GPS rows crash the tab with an array buffer error. https://www.jingweizhi.com/en/cookbook/deckgl-oom-large-data.html (accessed 2026-11-03).