Skip to content

Add load-time configuration to resize the node creation buffer #2102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jan 20, 2022

Conversation

jeffreylovitz
Copy link
Contributor

This PR adds the load-time configuration NODE_CREATION_BUFFER to allow users to modify the amount of empty space is reserved in matrices for future node creations.

Copy link
Contributor

@swilly22 swilly22 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep this PR simple
Today our matrices dimensions (NxN) are equal to the graph's node datablock itemCap, which is: number of blocks * DATABLOCK_BLOCK_CAP
I believe the idea was to allow the user to specify a different value which will become a replacement to the DATABLOCK_BLOCK_CAP specifically for the graph node's datablock.

consider

DataBlock *DataBlock_New
(
    uint64_t blockCap,    // max number of items in a single block
    uint64_t itemCount,   // initial number of items required
    uint itemSize, fpDestructor fp
);

to be compact we can use a small value for the blockCap in addition to passing 0 as itemCount

DataBlock *DataBlock_New(128, 0, (fpDestructor)FreeEntity);

@@ -57,6 +57,7 @@ class GraphTest : public ::testing::Test {
GrB_Index ncols, nrows, nvals;

// Create nodes.
Graph_AllocateNodes(g, node_count);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this call added?

@jeffreylovitz jeffreylovitz force-pushed the configurable-node-creation-buffer branch from 0fd3ad1 to 773d249 Compare January 18, 2022 21:40
@codecov
Copy link

codecov bot commented Jan 18, 2022

Codecov Report

Merging #2102 (efe7427) into master (e470522) will increase coverage by 0.01%.
The diff coverage is 93.18%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2102      +/-   ##
==========================================
+ Coverage   92.79%   92.81%   +0.01%     
==========================================
  Files         252      251       -1     
  Lines       22425    22451      +26     
==========================================
+ Hits        20810    20837      +27     
+ Misses       1615     1614       -1     
Impacted Files Coverage Δ
src/configuration/config.c 86.85% <89.80%> (+1.24%) ⬆️
src/util/datablock/datablock.c 95.41% <94.11%> (-0.29%) ⬇️
src/graph/graph.c 99.47% <100.00%> (-0.01%) ⬇️
src/graph/graphcontext.c 97.54% <100.00%> (+0.01%) ⬆️
src/resultset/resultset.c 97.97% <100.00%> (ø)
...rc/serializers/decoders/current/v11/decode_graph.c 96.66% <100.00%> (ø)
src/serializers/decoders/prev/v10/decode_graph.c 94.38% <100.00%> (ø)
...serializers/decoders/prev/v6/decode_graphcontext.c 100.00% <100.00%> (ø)
src/serializers/decoders/prev/v7/decode_graph.c 96.47% <100.00%> (ø)
src/serializers/decoders/prev/v8/decode_graph.c 96.73% <100.00%> (ø)
... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e470522...efe7427. Read the comment docs.

@jeffreylovitz jeffreylovitz force-pushed the configurable-node-creation-buffer branch from 0084708 to 34dde15 Compare January 19, 2022 17:14
@@ -140,10 +140,14 @@ This configuration can only be set when the module loads.

`NODE_CREATION_BUFFER` is 16,384 by default.

### Minimum

The minimum value for `NODE_CREATION_BUFFER` is 128. Values lower than this will be accepted as arguments, but will internally be converted to 128.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider always rounding up to a power of 2
so 200 will become 256

dataBlock->itemSize = itemSize + ITEM_HEADER_SIZE;
dataBlock->itemCount = 0;
dataBlock->blockCount = 0;
dataBlock->blockCap = blockCap;
Copy link
Contributor

@AviAvni AviAvni Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: move 2 lines up

@@ -13,23 +13,28 @@
#include <stdbool.h>

// Computes the number of blocks required to accommodate n items.
#define ITEM_COUNT_TO_BLOCK_COUNT(n) \
ceil((double)n / DATABLOCK_BLOCK_CAP)
#define ITEM_COUNT_TO_BLOCK_COUNT(n, cap) \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why need cap? can't we just write dataBlock->blockCap?

Copy link
Contributor

@swilly22 swilly22 Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this macro answers the question:
given n items how many blocks do we need to accommodate them?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes but we always pass dataBlock->blockCap to this macro

@@ -27,3 +27,4 @@ void *DataBlock_AllocateItemOutOfOrder(DataBlock *dataBlock, uint64_t idx);
* 1. Item distructor is not invoked in this call.
* 2. This call does not decrease the number of items in the data block. */
void DataBlock_MarkAsDeletedOutOfOrder(DataBlock *dataBlock, uint64_t idx);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the c file deleted why not delete this file too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clear separation of the API, but we could delete this one as-well, I just wanted to keep this API separated.

@swilly22 swilly22 merged commit 9ec0db8 into master Jan 20, 2022
@swilly22 swilly22 deleted the configurable-node-creation-buffer branch January 20, 2022 11:56
AviAvni pushed a commit that referenced this pull request Jan 20, 2022
* Add load-time configuration to resize the node creation buffer

* Revert changes to graph files

* Node creation buffer modifies datablock sizes

* refactor datablock, removed unused features

* Modify NODE_CREATION_BUFFER tests

* Node creation buffer is always a power of 2

Co-authored-by: swilly22 <[email protected]>
Co-authored-by: Roi Lipman <[email protected]>
swilly22 added a commit that referenced this pull request Jan 21, 2022
* Add load-time configuration to resize the node creation buffer (#2102)

* Add load-time configuration to resize the node creation buffer

* Revert changes to graph files

* Node creation buffer modifies datablock sizes

* refactor datablock, removed unused features

* Modify NODE_CREATION_BUFFER tests

* Node creation buffer is always a power of 2

Co-authored-by: swilly22 <[email protected]>
Co-authored-by: Roi Lipman <[email protected]>

* Address PR comments

* Bump readies dependency to latest version

* Fixed docker builder (build/docker)

Co-authored-by: Jeffrey Lovitz <[email protected]>
Co-authored-by: swilly22 <[email protected]>
Co-authored-by: Roi Lipman <[email protected]>
Co-authored-by: rafie <[email protected]>
pnxguide pushed a commit to CMU-SPEED/RedisGraph that referenced this pull request Mar 22, 2023
…Graph#2102)

* Add load-time configuration to resize the node creation buffer

* Revert changes to graph files

* Node creation buffer modifies datablock sizes

* refactor datablock, removed unused features

* Modify NODE_CREATION_BUFFER tests

* Node creation buffer is always a power of 2

Co-authored-by: swilly22 <[email protected]>
Co-authored-by: Roi Lipman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants