@benoitgrelard @jjenzz Just pinging this. This is causing serious overhead in our app. It would be great if we could have a solution in Radix that didn't incur a performance penalty for each additional menu. Thanks!

Looking at the code it seems any component using the following components could add N (N = number of components) listeners to the app causing it to be slow once the app gets large enough:

• DismissableLayer: will add N pointerDown, focusin events
• FocusScope: will add N focusin, focusout events
• DismissableLayer: will add N pointerDown, pointer move, keydown events
• RadioGroup: will add N keydown, keyup events
• useEscapeKeydown: will add N keydown events

@hipstersmoothie many of the components listed would only add events when the content parts are open so unlikely to be an issue unless you have 1000s of dialogs open at the same time (for example).

the issue with Menu is specifically because it is adding events in the Root part which will exist for all instances on the page (not just open content). the only one from your list that i can see is likely to suffer the same issues is RadioGroup.

@AlabasterAxe how many menus do you have rendered on your page? i'm not working at modulz anymore so i cannot help with a timeline for a solution to this i'm afraid but i'm surprised it is causing such a significant slow down.

you can see up to 500 menus (that also open dialogs) here performing fine: https://codesandbox.io/s/radix-performance-demo-forked-o6q977?file=/src/App.js

Nice thanks for the pointer! taking a look. I agree that example performs very well. Not sure why performance would be so different.

In the cases I've been looking at it was ~700.

Your page does reproduce the same issue:

The top-level task took 42 ms overall and 40ms of which is just handling the keydown event listeners. It's possible that if there's more going on on the page that these event handlers are slower to process? 🤷

Yeah this is easily reproducible with the given example. Here I upped the menus to 1000 and each keydown takes 140ms

Even downing it to 700 (matching our usage) see 80ms delays

This PR I opened does fix the issue though. 🙏ing we can get a merge

Here I upped the menus to 1000 and each keydown takes 140ms

while i agree it might be nice to reduce these events (to prevent the overhead of these reports if anything), if you're experiencing a performance issue from them i would think you are rendering far too many menus at once.

personally i would avoid rendering 500 menus let alone 1000 since it is unlikely to be possible for a human to interact with that many menus in a single viewport, so react will be redundantly managing those trees.

using something like IntersectionObserver/virtual scroll to render only the menus in the user's viewport will help your performance all round.

@jjenzz 100% agree, there's no reason we need to render many of those components since most of them are off-screen. I'm planning on looking into this soon.

At the same time, I think it's reasonable for these components to defensive about potential misuse, especially since in this case it seems like there are reasonable ways to avoid registering one listener per menu.

Hi @AlabasterAxe,

At the same time, I think it's reasonable for these components to defensive about potential misuse, especially since in this case it seems like there are reasonable ways to avoid registering one listener per menu.

Whilst this might be nice, it is clear that a lot more can be done user-side/app-side to ensure better performance.
Additionally, we have already reduced the numbers of listeners for each menu instance from 3 to 1 (#1140).

We have to prioritise where we focus our time so I will close this issue for now as it is unlikely we will do more in this case.

✌️