Performance issue rendering. 40k blocks in Blazor WebAssembly question

[진상훈]

Hello Blockly team,

In Blazor WebAssembly (.NET 8) we see severe lag when rendering ~40,000 blocks on a single workspace (very long initial render, unusable scroll/zoom, memory spikes).

• Is it expected that such a long, fully connected chain causes severe lag (slow initial render, unusable scroll/zoom, memory spikes)?

• We understand this may be an atypical pattern, but we must use a single-chain structure. Is there any recommended method (settings, renderer choice, batching/virtualization, architectural patterns) to make this viable?

[epas...@google.com]

Hi there,

I think you're going to have issues rendering that many blocks at once no matter what you do. The folks at AppInventor contributed a lot of performance improvements to Blockly over the years, but they've previously topped out at ~12k blocks in a single workspace (not all nested) and there's still some noticeable jankiness at that size.

A couple options you might consider:

- Simplify your API: a 40k block chain is going to be unreadable to most people. The main use case for blocks is to make things easier for people to understand. I'd recommend rethinking what this is used for and abstracting a lot of those into higher level chunks.

- Autocollapse sections: If your chain is connected via Next connections, you can introduce segment blocks that just contain a group of blocks and use the setCollapsed API to hide most of the blocks. To make it functional you'd probably want to add some additional UI controls to quickly expand/collapse sections.