How to Optimize Front-End Memory Usage for Massive Map Annotations

Annotations are one of the most basic elements of a map, indicating the name of each location or route. In the map JSAPI, the display effect and performance of annotations are key issues to solve.

The new version of Gaode map annotations adopts SDF (signed distance field) and reconstructs the entire annotation code, moving offset, avoidance, and triangulation calculations to the front‑end, which dramatically increases computation and memory consumption.

For example, in a 3D scene with around ten thousand text‑bearing annotations, the vertex count can reach about 2.5 million, requiring roughly 10 MB of memory when stored in a Float32Array.

Front‑End Memory Overview

Memory in JavaScript is divided into heap and stack . The stack stores simple data types (numbers, strings, booleans, and references to complex types), while the heap stores complex structures such as objects and arrays.

Simple data types stored on the stack are accessed faster than complex types on the heap. A demo comparing write performance shows that writing to stack variables is noticeably quicker than writing to heap objects.

function inStack(){
  let number = 1E5;
  var a;
  while(number--){
    a = 1;
  }
}

var obj = {};
function inHeap(){
  let number = 1E5;
  while(number--){
    obj.key = 1;
  }
}

Object and Array Storage

JavaScript objects are stored using a hash table. Each property is mapped to a storage address via a hash function, which must balance simplicity and collision avoidance. Common collision‑resolution methods include open addressing, rehashing, and chaining (the article uses chaining).

Arrays in JavaScript are essentially objects with numeric keys, giving them great flexibility but also preventing true contiguous memory layout. This leads to performance penalties when handling massive data sets.

TypedArray and DataView

TypedArray (e.g., Int8Array, Float32Array) provides a fixed‑length, contiguous memory block, while DataView offers flexible read/write of different types on an ArrayBuffer. Performance tests show that TypedArray is generally faster than DataView, though recent V8 optimizations narrow the gap.

// TypedArray example
var typedArray = new Int8Array(10);
typedArray[0] = 8;
typedArray[1] = 127;
typedArray[2] = 128; // wraps to -128
console.log("typedArray", typedArray);

// DataView example
var buffer = new ArrayBuffer(8 * 10);
var view = new DataView(buffer);
view.setInt8(0, 2);
view.setFloat32(8, 65535);
console.log(view.getInt8(0)); // 2
console.log(view.getFloat32(8)); // 65535

Shared Memory (SharedArrayBuffer) for Multi‑Thread Communication

Web Workers run on separate threads and normally communicate via postMessage, which clones data and incurs overhead. Using SharedArrayBuffer allows threads to share the same memory, eliminating the copy step and dramatically improving performance for large data volumes.

Performance tests show that while the benefit is modest for 10 万 items, it becomes significant when handling millions of items.

Memory Detection and Garbage Collection

Chrome’s DevTools Memory panel can be used to take heap snapshots and analyze memory usage. JavaScript’s garbage collector (typically a mark‑and‑sweep algorithm) automatically reclaims memory, but developers should minimize unnecessary allocations to reduce GC pauses.

Conclusion

When creating data structures in the front‑end, choose the most suitable storage based on the scenario:

For small data sets, use ordinary arrays for flexibility.

For large data sets, use TypedArray or DataView to allocate a contiguous memory block.

For inter‑thread communication with large payloads, use SharedArrayBuffer.

Use Chrome’s Memory tools to detect issues and understand GC behavior to avoid unnecessary CPU consumption.

Applying these strategies to massive map annotations—using TypedArray for storage and performing heavy calculations in workers—significantly reduces memory allocation and GC overhead, leading to better performance.