Creating ArrayBuffers is comparatively expensive, and the intended way of using them is to share a single buffer between multiple TypedArrays (or DataViews) pointing to different regions of the buffer using offsets. For the same reason, it is better to use simple Arrays instead of TypedArrays for short-lived objects. Recently I have come across a seemingly popular library that would mimic C types by creating a whole new ArrayBuffer for each primitive value it gets... with predictably poor performance.
Memory Efficient Graphs
To deal with large graphs efficiently, structurae offers classes implementing adjacency matrix and list for both weighted and unweighted graphs. Internally, the structures use ArrayBuffers to hold the adjacency information in the densest possible way. As an example, for an unweighted graph, the adjacency matrix uses a single bit in an underlying ArrayBuffer to denote an edge between two nodes. For weighted matrices, we use
Grid variations that result in an “unrolled” TypedArray using a single ArrayBuffer. For sparse graphs, we have adjacency list implementations that also rely on TypedArrays and require less space, however, editing operations on lists are slower due to a possible shifting of values when edges are added or removed.
RankedBitArray that is often used for implementing succinct structures.
The adjacency structures above serve as basic classes for implementing graphs. Structurae also has the
Graph class that extends a given adjacency structure with common methods for graph traversal, pathfinding, tree creation, etc:
The Joy of C-like Strings
Uint8Array and encodes into UTF8.
To take further advantage of the API, structurae introduces
StringView class that extends
Uint8Array with common string related methods such as
StringView methods are usually slower than their counterparts for strings, avoiding conversions while dealing with binary data can boost the overall performance.
There is a catch, though, when WebAssembly’s Memory grows, the typed arrays we use as “views” into it become detached, i.e. out of sync with WebAssembly. The issue along with the proposed solution⁸ is currently actively discussed. For now, however, we will have to keep track of the memory by ourselves.