GDS Feature Toggles

Feature toggles are not considered part of the public API and can be removed or changed between minor releases of the GDS Library.
Feature toggles are not available in AuraDS.

BitIdMap Feature Toggle

GDS Enterprise Edition uses a different in-memory graph implementation that is consuming less memory compared to the GDS Community Edition. This in-memory graph implementation performance depends on the underlying graph size and topology. It can be slower for write procedures and graph creation of smaller graphs. To switch to the more memory intensive implementation used in GDS Community Edition you can disable this feature by using the following procedure call.

CALL gds.features.useBitIdMap(false)

Packed Adjacency List Toggle

The in-memory graph for GDS is based on the Compressed Sparse Row (CSR) layout. By default, the adjacency list for a single node within the CSR data structure is stored compressed using a combination of variable-length- and delta-encoding. The compression strategy can be changed to uncompressed or to an integer packing approach.

Integer packing is an alternative compression strategy in GDS that - compared to the default compression - leads to an at least similar but mostly better compression ratio. A better compression ratio results in a reduced memory consumption of an in-memory graph, i.e., we can fit more graph data into the same amount of memory. In terms of compression performance, integer packing achieves a better compression performance than the default compression. While the compression performance is better, a graph projection will mostly be as fast as before as the runtime is not necessarily dominated by compressing relationship, but by other parts of the graph projection, such as id mapping or property loading. The decompression performance is always better than the default compression strategy, due to better memory locality and less branching. Traversal-heavy algorithms in particular will benefit from this performance gain.

One important difference compared to the default compression strategy is that the integer packing implementation uses off-heap memory to store the CSR data structure. This needs to be considered when sizing JVM heap and page cache memory for Neo4j and the remaining OS memory. If the feature is enabled, data will be stored in the memory region that is shared with the OS, similar to the page cache, but without a size limitation. If there is not enough free memory available during graph projection, the allocation will lead to undefined behaviour and most likely a crashing JVM.

To switch to using packed adjacency lists, use the following procedure call.

CALL gds.features.usePackedAdjacencyList(true)

To switch back to default compression or uncompressed (if enabled) adjacency lists, use the following procedure call.

CALL gds.features.usePackedAdjacencyList(false)

To reset the setting to the default value, use the following procedure call.

CALL gds.features.usePackedAdjacencyList.reset() YIELD enabled

Uncompressed Adjacency List Toggle

The in-memory graph for GDS is based on the Compressed Sparse Row (CSR) layout. By default, the adjacency list for a single node within the CSR data structure is stored compressed. That compression lowers the memory usage for a graph but requires additional computation time to decompress during algorithm execution. Using an uncompressed adjacency list will result in higher memory consumption in order to provide faster traversals. It can also have negative performance impacts due to the increased resident memory size. Using more memory requires a higher memory bandwidth to read the same adjacency list. Whether compressed or uncompressed is better heavily depends on the topology of the graph and the algorithm. Algorithms that are traversal heavy, such as triangle counting, have a higher chance of benefiting from an uncompressed adjacency list. Very dense nodes in graphs with a very skewed degree distribution ("power law") often achieve a higher compression ratio. Using the uncompressed adjacency list on those graphs has a higher chance of running into memory bandwidth limitations.

To switch to uncompressed adjacency lists, use the following procedure call.

CALL gds.features.useUncompressedAdjacencyList(true)

To switch to compressed adjacency lists, use the following procedure call.

CALL gds.features.useUncompressedAdjacencyList(false)

To reset the setting to the default value, use the following procedure call.

CALL gds.features.useUncompressedAdjacencyList.reset() YIELD enabled

Reordered Adjacency List Toggle

The in-memory graph for GDS writes adjacency lists out of order due to the way the data is read from the underlying store. This feature toggle will add a step during graph creation in which the adjacency lists will be reordered to follow the internal node ids. That reordering results in a CSR representation that is closer to the textbook layout, where the adjacency lists are written in node id order. Reordering can have benefits for some graphs and some algorithms because adjacency lists that will be traversed by the same thread are more likely to be stored close together in memory (caches). The order depends on the GDS internal node ids that are assigned in the in-memory graph and not on the node ids loaded from the underlying Neo4j store.

To enable reordering, use the following procedure call.

CALL gds.features.useReorderedAdjacencyList(true)

To disable reordering, use the following procedure call.

CALL gds.features.useReorderedAdjacencyList(false)

To reset the setting to the default value, use the following procedure call.

CALL gds.features.useReorderedAdjacencyList.reset() YIELD enabled