# Performance Tuning#

Memory footprint and performance on large-scale graph data are the keys to the success of graph analysis in real-world scenarios. In this section, We’ll go through the internal design of the property graph data structure in GraphScope, analyze the impact factor of memory footprint and performance, and finally give some suggestions on how to optimize the performance and reduce the memory usage of graph analysis.

## Memory Footprint of Property Graphs#

We first dive into the detailed design of the property graph data structure to see how it is stored in memory and which factors affect the memory footprint.

### Property graph data structure#

GraphScope uses the `ArrowFragment`

data structure defined in Vineyard for
its property graphs. Basically, the `ArrowFragment`

has the following members:

Indexers: the vertices in the user input graphs are natural integral numbers or strings. To make the graph analytical processing efficient, we need to map the original IDs in the user input to a consecutive range of integral numbers. This process requires a data structure called

`VertexMap`

, which is basically a hashmap which maps the original vertex ID to the internal vertex ID and an array which record the original vertex IDs in each partition.`o2g_<fragment_id>_<vertex_label>`

: vertices in each partition for each label has such a hashmap. The hashmap is either flatten hashmap or perfect hashmap.The key type of the hashmap is the same with the original vertex IDs (usually

`int64_t`

or`std::string_view`

) and the value type is the internal vertex ID (usually`uint64_t`

).`oid_arrays_<fragment_id>_<vertex_label>`

: arrays for original vertex IDs in each partition for each label.The type of this array is the same with the original vertex IDs (usually

`int64_t`

or`string`

).

Topologies: the first major part of the property graph is the topology: it basically a CSR (Compressed Sparse Row Format) matrix:

incoming edges: each

`(src_type, edge_type)`

pair has a CSR matrix for its incoming edges. The CSR matrix consists of a`indptr`

array and a`indices`

array:`ie_lists_-<vertex_label>-<edge_label>`

: the`indptr`

array, each element in the`indptr`

array is a`(neighbor_vertex_id, edge_table_index)`

pair where the first the neighbor vertex id and the second is the index points to the corresponding edge table.By default, the type of

`neighbor_vertex_id`

is`uint64_t`

or`uint32_t`

and the type of`edge_table_index`

is`size_t`

.The size of the

`indptr`

array is`num_edges`

.`ie_offsets_lists_-<vertex_label>-<edge_label>`

: the`indices`

array, each element in the`indices`

array is an`offset`

, and the slice`ie_lists[ie_offsets[i]:ie_offsets[i+1]]`

is the edges for vertex`i`

.By default, the type of

`offset`

is`size_t`

.The size of

`indices`

aray is`num_vertices + 1`

, which is a 0-based offset array.

outgoing edges: a CSR matrix, same as the incoming edges, but for outgoing edges of current partition.

`oe_lists_-<vertex_label>-<edge_label>`

: the`indptr`

array, each element in the`indptr`

array is a`(neighbor_vertex_id, edge_table_index)`

pair where the first the neighbor vertex id and the second is the index points to the corresponding edge table.By default, the type of

`neighbor_vertex_id`

is`uint64_t`

or`uint32_t`

and the type of`edge_table_index`

is`size_t`

.The size of the

`indptr`

array is`num_edges`

.`oe_offsets_lists_-<vertex_label>-<edge_label>`

: the`indices`

array, each element in the`indices`

array is an`offset`

, and the slice`oe_lists[oe_offsets[i]:oe_offsets[i+1]]`

is the edges for vertex`i`

.By default, the type of

`offset`

is`size_t`

.The size of

`indices`

aray is`num_vertices + 1`

, which is a 0-based offset array.

Properties: the second part of the property graph is the properties: each vertex label and each edge label has a table for its properties:

`edge_tables_-<edge_label>`

: tables for edge properties, each edge label has such a table;`vertex_tables_-<vertex_label>`

: tables for vertex properties, each vertex label has such a table.

### Memory usage estimation#

The memory usage of a given fragment with vertex number `V`

, edge number `E`

, original
ID type `OID_T`

and internal ID type `VID_T`

can be
estimated as:

Indexers:

with flatten hashmap:

`(sizeof(OID_T) + sizeof(VID_T) + sizeof(uint8_t)) * V / load_factor`

;From the observation in our practices, the

`load_factory`

is usually within the range of`[0.4, 0.5]`

.with perfect hashmap:

`(sizeof(OID_T) * V) * (1 + overhead)`

.In practice the

`overhead`

is usually within the range of`[0.15, 0.2]`

.

Topologies:

incoming edges:

`(sizeof(VID_T) + sizeof(size_t)) * E + sizeof(size_t) * (V+1)`

;outgoing edges: same as incoming edges,

`(sizeof(VID_T) + sizeof(size_t)) * E + sizeof(size_t) * (V+1)`

.

Properties:

edge properties: depends on how many edge properties you have.

In GraphScope, by default the an extra column

`edge_id`

property (of type`int64_t`

) will be generated and added to the edge table as a unique identifier for each edge.vertex properties: depends on how many vertex properties you have.

In GraphScope, by default the original vertex ID is kept as a property in the vertex table as well.

## Optimizing Memory Usage#

Based on the above analysis, we summary the optimization tips of reducing fragment memory footprint as follows:

Optimizing indexers:

Use perfect hashmap. It is not the default option but can be enabled by the argument

`use_perfect_hash=True`

in`graphscope.g()`

and`graphscope.load_from()`

.As analyzed above, the perfect hashmap can reduce the memory footprint of vertex map for a really large margin.

Use local vertex map. GraphScope internally has two kinds of vertex map implemented, the former is called

`GlobalVertexMap`

which stores all vertices in all fragments in the indexer, the later is called`LocalVertexMap`

which only stores related vertices (vertices that has edges between inner vertices of current fragment) in the indexer.The

`LocalVertexMap`

is not the default option but can be enabled by the argument`vertex_map="local"`

in`graphscope.load_from()`

. The`LocalVertexMap`

is suitable for graphs which will scales to many nodes (e.g., dozens or hundreds of workers), but it does has some limitations on the flexibility that can only used when loading graphs using`graphscope.load_from()`

and repeatedly`add_vertices/edges()`

are not supported.

Optimizing topologies:

GraphScope uses

`uint64_t`

as the`VID_T`

(internal vertex id) to support large-scale graphs. However, from above analysis, the type of`VID_T`

is one of the key factors that affects the memory footprint of the topology part.If you are sure your graph is fairly small (less than

`10^8`

of vertices, the absolute value depends on number of labels and number of partitions), you can use`int32_t`

as the`VID_T`

to optimize the memory usage, by`vid_type="int32_t"`

option in`graphscope.g()`

and`graphscope.load_from()`

.sGraphScope supports options

`compact_edges=True`

in`graphscope.g()`

and`graphscope.load_from()`

to compact the`ie_lists`

and`oe_lists`

arrays using delta and varint encoding. Such compression can half the memory footprint of the topology part, but has overhead in computation during traversing the fragment that can up to`20%`

.

Optimize properties:

The generation of

`edge_id`

column in the edge tables can be avoided by the argument`generated_eid=False`

in`graphscope.g()`

and`graphscope.load_from()`

. This helps a a lot (saves`sizeof(size_t) * E`

) if your edges doesn’t much many properties and you only need to run efficient analytical jobs.Note that if you intend to run interactive queries on the graph, the argument

`generated_eid`

must be`True`

.The preservation of

`vertex_id`

column in the vertex tables can be avoided by the argument`retain_oid=False`

in`graphscope.g()`

and`graphscope.load_from()`

. It helps not very much (saves`sizeof(OID_T) * V`

) but the gain can be more significant if your graph has low`E/V`

ratio (graphs has many vertices and not so many edges).Note that if you intend to run interactive queries on the graph, the argument

`retain_oid`

must be`True`

.

## Optimizing Performance of Graph Analytics#

GraphScope supports analytical applications on both `ArrowFragment`

graphs with many vertex
labels, edge labels, and properties, as well as `ArrowProjectedFragment`

graphs with only
one vertex label, one edge label, and at most one property for each vertex and edge.

The analytical applications on

`ArrowFragment`

requires an implicit “flatten” process to make it a`ArrowFlattenFragment`

.The

`ArrowFlattenFragment`

can be thought as a “view” on the property graph`ArrowFragment`

. It is mainly for compatibility purpose and has performance penalty for traversing. In practice if the performance of analytical applications is critical, flatten fragments should be avoid and projected fragments should be used instead.The analytical applications on

`ArrowProjectFragment`

requires an implicit “project” process to create the`ArrowProjectedFragment`

. This process involves traversing the edges and generating a new`offsets`

arrays.To optimizing the run time in cases where you need to run many different algorithms on the same graph using the same projection settings, it is preferred to project the fragment explicitly to

`ArrowProjectFragment`

first to avoid the overhead of the “project” process. i.e.,Instead of:

g = .... # fragment that can be implicit projected r1 = sssp(g, src=1) r2 = pagerank(g) r3 = wcc(g) ...

You should first project it explicitly:

g = .... # fragment that can be implicit projected projected_g = g._project_to_simple() r1 = sssp(projected_g, src=1) r2 = pagerank(projected_g) r3 = wcc(projected_g)

When apply analytical algorithms on `ArrowFragment`

, if (1) it has only one vertex label, (2)
it has only one edge label, and (3) each vertex and edge has at most one property, then
the `ArrowProjectedFragment`

will be generated, otherwise, the `ArrowFlattenFragment`

will be used.