VS Code freezes/crashes when loading a large register set (~500K lines)

[QuocTrung76]

Type: Bug Report

Describe the bug

• OS and Version: Windows 11 / Ubuntu 22.04
• VS Code Version: 1.106.0
• Extension Version: 1.8.1
• Target Device: R-Car ARM
• Other extensions you installed (and if the issue persists after disabling them): Renesas Debug
• When the extension requests a large amount of register information from the adapter, the response time becomes noticeably slow. As the number of registers increases, the UI becomes unresponsive. This also affects other extensions—such as Renesas Debug—which stop functioning properly once the UI hangs. If close the Peripheral View, the debugging works normally.

Expected behavior

The Peripheral View should handle large register sets more efficiently to prevent UI freezes and ensure other extensions remain functional.

Screenshots

Additional context

[QuocTrung76]

I believe this issue occurs because the Peripheral View is continuously refreshing for some reason. Additionally, when the extension executes a large number of customRequest calls—one per register—the problem becomes unavoidable. As the number of registers grows, the extension ends up sending a massive amount of customRequest operations, which eventually overwhelms the system and causes the UI to hang.

[jonahgraham]

The default refresh mode is always:

vscode-peripheral-inspector/src/manifest.ts

Line 30 in 7956d67

export const DEFAULT_PERIODIC_REFRESH_MODE: PeriodicRefreshMode = 'always';

And there are somc commands to change this:

vscode-peripheral-inspector/package.json

Lines 154 to 162 in 7956d67

	"command": "peripheral-inspector.svd.periodicRefreshMode",
	"title": "Set Periodic Refresh Mode",
	"icon": "$(refresh)"
	},
	{
	"command": "peripheral-inspector.svd.periodicRefreshInterval",
	"title": "Set Periodic Refresh Interval",
	"icon": "$(calendar)"
	}

[jreineckearm]

The commands are for context menu entries in the viewer.

Default should actually be off:

vscode-peripheral-inspector/package.json

Line 404 in 7956d67

"default": "off",

But agree, that this default value probably should also be reflected in the manifest file.

Did you probably receive a reproducer with the setting set to always in workspace settings?
Look out for a file .vscode/settings.json in the workspace if you use VS Code.

[QuocTrung76]

Thank you for sharing. The periodic refresh customization resolves my initial issue. However, when the number of nodes becomes large, the UI still hangs whenever I manually refresh the Peripheral view (after turning off periodic mode and using the refresh button). I'm not sure whether the UI freeze is caused by a UI optimization issue or by the connection with the adapter.

[QuocTrung76]

I think the issue is mainly due to limitations in the VS Code UI. When the TreeView tries to create too many nodes, it can cause the UI to freeze and impact other operations. If that's the case, then this is likely also a limitation of the Peripheral View when handling a large number of registers. I appreciate your thoughts on this. Thank you.

[jreineckearm]

A few more questions:

• You write "500K lines". I assume you expanded many nodes? Or is there few peripherals with thousands of registers each?
• To assess the immediate impact: is this coming back from a user or from a validation activity? And do you expect users to often expand this large number of lines?
• Can one recover from the situation within a session? Or would you need to close it (or even VS Code)?

I believe this needs some attention. Crashes and freezing are never good things. But we also need to understand how often this happens in reality.

IIRC, we currently build the whole tree for the WebView and not only what's in the visible scrolling range. @martin-fleck-at , can you confirm that?

Things to investigate

• Can the underlying GUI library be used differently to only create the relevant parts of the tree. Or has it evolve since and offers more capabilities these days.
  • https://ant.design/components/overview/ through https://github.com/eclipse-cdt-cloud/vscode-ui-components
• Would it be a viable approach to limit the number of expanded nodes and discard child nodes when collapsing the parents? Users would then be asked to close other nodes if hitting the limit. May become a little fiddly around the edges though.
• Do we need to rethink the whole approach of having all peripherals in a single view? This aligns with some feedback we got in the past. But I don't have clear vision yet how to manage multiple views in the VS Code sidebars dynamically. And moving to the editor area also has disadvantages as you are competing with source files which might need a little more real estate. We learnt that with the Memory Inspector.

I am afraid, my team doesn't have a lot bandwidth at the moment to focus on this (holiday season coming up and priorities in other areas). So, any help with investigations would be appreciated if this is urgent for you.

[martin-fleck-at]

@jreineckearm If I remember correctly we only render the items that are actually visible (virtualization) but still build up the complete tree for search in advance (no lazy loading).

[QuocTrung76]

Hi @jreineckearm , By “500K lines,” I am referring to the content of the SVD file, which includes registers, clusters, and fields. In practice, this corresponds to roughly 500K nodes in the implementation.

I reproduced the issue by simply scrolling the view and resizing a column, without triggering any edit or node update. Even with all registers collapsed, VS Code still became unresponsive.

If I choose Keep Waiting, VS Code eventually recovers and the debug session continues, but this takes a noticeable amount of time.

In the attached image, I was attempting to expand the first register and then VS Code appeared to crash. After pressing Keep Waiting and waiting for a short period, the register was expanded successfully and the debug session resumed.

Based on this investigation, I suspect that the issue is related to the rendering process when the number of nodes becomes very large. However, I do not have much experience with the vscode-ui-component in this area.

I will continue investigating and share any findings, and I would greatly appreciate your support or guidance in the meantime. Thank you in advance.

[jonahgraham]

My guess is that the same approach in this tree to large data sets needs to be taken as some debug components do. For example if there is a very large array, instead of displaying that flat in the tree view it is grouped into smaller sections:

By doing this there is never more than (e.g.) 1000 additional nodes that need to be rendered on any tree operation means the UI will stay responsive.

@QuocTrung76 If the above is correct, can you provide a PR that automatically groups peripherals if there are more than a certain number of them?

[QuocTrung76]

Hi @jonahgraham , This resolved my issue. I made a small UI change (React components) by introducing an additional node type to group nodes; I refer to these as “group nodes”, which currently exist only on the UI side.

However, I’m encountering some UI issues when expanding these group nodes. Because they are not recognized by the back end, this sometimes leads to UI errors. I’m currently investigating this, but I’d like your recommendation on whether it would be better to also adjust the back end to keep things synchronized, or if a UI-only change should be sufficient.

In addition, I have a few design decisions where I’d appreciate your guidance:

• Should we group nodes at all levels? I’ve tried grouping the two outermost levels, and it significantly reduced the UI load. So far, this approach has avoided crashes and hangs.

• Is there a recommended number of items to include in a single group? By now, I started with 20 items in a group. Please note that number of level 1 nodes (in attached image) is about 300 - 400, and the level 2 nodes could be up to 400. For some devices, the number could be less or greater.

• If back-end changes are necessary, I’m considering introducing a new class (e.g. PeripheralGroupNode) to represent grouped nodes.

• If a UI-only approach is sufficient, should I also investigate changes in vscode-ui-components? I suspect the current issue may stem from limitations there when handling UI-only grouping.

Below is the result after applying the UI-side changes:

[jonahgraham]

Hi @jonahgraham , This resolved my issue. I made a small UI change (React components) by introducing an additional node type to group nodes; I refer to these as “group nodes”, which currently exist only on the UI side.

@QuocTrung76 Great that you have confirmed the issue can be resolved by grouping.

However, I’m encountering some UI issues when expanding these group nodes. Because they are not recognized by the back end, this sometimes leads to UI errors. I’m currently investigating this, but I’d like your recommendation on whether it would be better to also adjust the back end to keep things synchronized, or if a UI-only change should be sufficient.

I don't know the implementation of the peripheral inspector well enough to answer this question. Perhaps share (as a draft PR) your work in progress so we can have a concrete thing to discuss. My guess is that you don't want to change the backend and handle it all as a display side. The caveat is that by changing front-end you handle only the UI performance problems. The amount of data transferred may still be very large, which is why the debug adapter protocol in some scenarios supports paging (e.g Scope.namedVariables)

In addition, I have a few design decisions where I’d appreciate your guidance:

• Should we group nodes at all levels? I’ve tried grouping the two outermost levels, and it significantly reduced the UI load. So far, this approach has avoided crashes and hangs.

Without knowing how you have done the grouping, I am not sure. I assume you should do it all the way down the hierarchy so that we don't hit the problem of a sub-node being too big.

• Is there a recommended number of items to include in a single group? By now, I started with 20 items in a group. Please note that number of level 1 nodes (in attached image) is about 300 - 400, and the level 2 nodes could be up to 400. For some devices, the number could be less or greater.

20 items seems quite low, in the screenshot I shared in #71 (comment) the grouping is 1000 items. I assume that the vscode tree component happily supports 1000 nodes.

Note that if you have 20 per group, you should have multiple levels so that there is no more than 20 per level in a branch of the tree. i.e. for your 500,000 nodes, something like:

- [0..24999]
  - [0..1249]
    - [0..62]
      - [0..20]
        - REG1
        - REG2
        - REG3
        - ... etc ...
      - [21..39]
      - [40..59]
      - [60..62]
    - [62..125]
      - [62..82]
        - REG63
        - REG64
        - REG65
        - ... etc ...
      - [83..102]
      - ... etc ...
    - [125...187]
    - ... etc ...
  - [1250..2499]
  - ... etc ...
[25000..49999]
- ... etc ...

I think 20 per group max as above is too little, for max of 1000 the 500k nodes looks a little like:

- [0..499]
  - REG1
  - REG2
  - REG3
  - ... etc...
- [500..999]
  - REG501
  - REG502
  - ... etc...
- ... etc...

There should not be a group if the number of elements in the group is less than your max number.

• If back-end changes are necessary, I’m considering introducing a new class (e.g. PeripheralGroupNode) to represent grouped nodes.
• If a UI-only approach is sufficient, should I also investigate changes in vscode-ui-components? I suspect the current issue may stem from limitations there when handling UI-only grouping.

If you can make a generic change to vscode-ui-components, that may be very useful, I am unsure how much work that would be.

PS is it necessary to block (red) out part of your screenshots?

[jreineckearm]

Thanks, @QuocTrung76 and @jonahgraham , for driving this further. I'll try to catch up on this next week. Unfortunately, busy until then. Will at least try to find a board with a comparably large SVD file to reproduce on my end.

Unfortunately, I can't comment from the top of my head on implementation details. It's been a while and I need to get up to speed again with this code.

I fully appreciate that we need to do something about it. And that paging suggested by @jonahgraham may be the way forward. My only concern is the significant GUI and navigation experience change. It will make it harder to spot peripheral names you are looking for by just scrolling through the view. Hence, we need to understand how widely this causes trouble and if we

• can find a good threshold to activate additional paging.
• should make it optional.
• or maybe even can find another solution to deal with it without paging.

Note, that the extra hierarchy level might also impact other features of the view like search, export/save values, etc.