Re-rendering full Graph after sub-graph causes Significant performance drop

[IuriiG]

Expected Behavior

It should be possible to render the full graph after rendering a sub-graph without a significant performance penalty.

The following example is expected to work efficiently:

const blocks = [ /* blocks of the full graph */ ];
const connections = [ /* connections of the full graph */ ];

const graph = new Graph({ blocks, connections });

// Render a sub-graph
const { blocks: subGraphBlocks, connections: subGraphConnections } = getSubGraph(blocks, connections);

graph.setEntities({
    blocks: subGraphBlocks,
    connections: subGraphConnections,
});

// Re-render the full graph
// ⚠️ This step takes significantly longer due to recalculating styles
graph.setEntities({
    blocks,
    connections,
});

In this scenario, re-rendering the full graph after rendering the sub-graph takes around 25 seconds for ~2000 blocks, whereas the initial render of the same graph takes less than 0.5 seconds.

Workaround

A temporary solution is to force a full re-render by assigning a new key to the GraphCanvas (or BlocksList) component each time setEntities is called.

[draedful]

Hi, can you help with an example to reproduce the problem? I created a story to check, but in the current story written according to the script in issue, the problem is not reproduced.

Story playground
Story code

[IuriiG]

Sorry, my bad — I oversimplified the code and only included the main milestones. In that context, the setEntities method triggers the rendering of the new graph. And yes, it is works fast.

The issue lies in the rendering process: the Graph starts rendering immediately, especially the canvas layer. However, rendering the detailed view (React components) takes time.

I suspect the problem is in the BlockList component. Re-rendering the component from scratch — by unmounting and remounting it using a new key each time — seems to fix the issue. At least it works well enough in my case.

Maybe you should try creating a more complex detailed view for the block or increase amount of blocks (I've tried 10k) to better reproduce the issue (in my opinion the issue related to detailed view using react components).

Also, I'm not using groups — that might be affecting the behavior, but I'm not sure.

[draedful]

@IuriiG Hi, can you check this case on the latest version of the library? We made several critical changes that could fix this error.

[IuriiG]

@IuriiG Hi, can you check this case on the latest version of the library? We made several critical changes that could fix this error.

@draedful I tried migrating the code from version 0.4.2 to version 1.1.4. This particular case no longer takes as much time. It's still slow, but noticeably faster than in 0.4.2 (26 seconds → 3 seconds). However, overall, the performance of version 0.4.2 is better. During the migration, there was a noticeable drop in FPS. It's clearly visible to the naked eye. There might be some inefficient usage somewhere, since many workarounds were added to make it work with 0.4.2. Amount of node more then 10000

[draedful]

@IuriiG Hi, can you check this case on the latest version of the library? We made several critical changes that could fix this error.

@draedful I tried migrating the code from version 0.4.2 to version 1.1.4. This particular case no longer takes as much time. It's still slow, but noticeably faster than in 0.4.2 (26 seconds → 3 seconds). However, overall, the performance of version 0.4.2 is better. During the migration, there was a noticeable drop in FPS. It's clearly visible to the naked eye. There might be some inefficient usage somewhere, since many workarounds were added to make it work with 0.4.2. Amount of node more then 10000

Hmm, this is very interesting, can you create an example to reproduce your case on stackblitz? https://stackblitz.com/edit/scaffold-gravity-graph?file=src%2FApp.tsx