GDS Feature Toggles

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.

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

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

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

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.

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

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

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.

To disable reordering, use the following procedure call.

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