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.

1. 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)

2. ShardedIdMap Feature Toggle

The BitIdMap is optimized for a low memory footprint when used together with a Neo4j database. However, its memory footprint is not optimal if the range of possible original node ids exceeds the node count significantly. In this situation the ShardedIdMap can be used to significantly reduce the required memory of the graph projection. To enable the sharded id map the following procedure call can be used:

CALL gds.features.useShardedIdMap(true)

3. Uncompressed Adjacency List Toggle

The in-memory graph for GDS is based on the Compressed Sparse Row (CSR) layout and uses compressed adjacency lists by default. The 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

4. 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