<Select> performance (large lists)

[hollow sierra]

memo has little effect over <Select> (large lists)

I ended up using memo + disabling strict mode + adding limite = {30 }and its fine now

[topaz swallow]

Curious about this, why would you have something like this? the only thing that i could think would be useful is if your list is huge and have some performance issues and even then i would argue it would be best to just virtualized your list rather than using a memo in the component. just wondering about the case

[hollow sierra]

Im not sure what you mean by virtualize

my knowledge about memo is basically non-existent. I got this suggestion by ChatGPT and it helped a bit.

export const countryOptions = Object.entries(isoCountries).map(([, country]) => ({
    value: country.code,
    label: country.name,
}))```

[topaz swallow]

I think memo in this case is not useful, because your list is really not that huge, if it was a list with 1000 of record or more perhaps, and even then i would argue that the solution is not memo the component

[hollow sierra]

yes even with memo I have the warning that focus in takes more than 200ms

there has to be an issue somewhere

could be due to Select implementation

[topaz swallow]

what i mean in terms of virtualize is something like this, only show the items as the user scrolls, so the elements are there https://tanstack.com/virtual/latest/docs/introduction in this case for example you can see what the docs say about it

[hollow sierra]

oh yes, indeed, i see what you mean

same like in ios

reuse cells sort of

[topaz swallow]

yeah, for example in react-native that i am most aware of you have the concept of virtualizedList

and it is useful if you have a pretty long list

[hollow sierra]

@topaz swallow the fact that disabling React strict mode improves perfomances is a hint that there is a useEffect inside Select that runs twice

Also maybe I should try the uncontrolled version

https://github.com/mantinedev/mantine/blob/master/packages/%40mantine/core/src/components/Select/Select.tsx

there are indeed several useEffects

[topaz swallow]

do you have a useEffect on your implementation of it? or the component? because for example I am using Combobox which is just a select and using the useUncontrolled hook

[hollow sierra]

no, I don't, it's the useEffect inside Mantine Select

I linked the source file

I should defo try the uncontrolled version

It was the first time I used Select, usually I use NativeSelect

[topaz swallow]

Yeah, ok i saw it intersting. I of course do not know your use case for it. but maybe you could try to build your own select you would have more control over it

I for example at work had to build a multiselect combobox, and used the hooks and primitives from mantine, and since there are times the list goes over 1000 i virtualized the list

[hollow sierra]

good stuff, I'll try to debug more and come back to you if i'm stuck

[hollow sierra]

so the slowdown is caused by the filter default implementation

when I replace it with filter={() => []} it removes the lag

🤣 Never mind, the issue was only in dev mode, probably due to Vite

Wait Im gonna show the visual trace

[topaz swallow]

LOL are you sure? i am really never had any issue. but glad it got fixed

personally, i almost never use memo its one those things that react is more complicated than it should

[hollow sierra]

this is dev mode

with CPUx20 slowdown

there seems something related to node modules

in Production (after built), the same function call is now 300ms (with CPUx20) slowdown

wait, Im gonna try again without the ignore list

so i can find the offender

[topaz swallow]

thats interesting, i mean in production things are usually a lot faster than in dev, because you're downloading everything at once, So really not sure how node_modules or vite would be in play here

[hollow sierra]

well, I've hit the limit of by debug abilities

🫠 💀

Mantine Core Component (OptionsDropdown):

The OptionsDropdown component from @mantine/core appears to be involved in the rendering process, taking 62.5 ms.
Its child (anonymous) function, likely related to JSX rendering, took 61.1 ms.

Floating UI calculations (computePosition, isRTL):

There's a Run console task which contains computePosition2 (20.8 ms) from @floating-ui/dom/dist/floating-ui.dom.mjs and computePosition (20.8 ms) from @floating-ui/core/dist/floating-ui.core.mjs, as well as isRTL (20.8 ms). These are likely related to positioning UI elements, possibly a dropdown or tooltip.

Recalculate style:
A Recalculate style event took 21 ms, indicating that changes to the DOM triggered a recalculation of styles, which can be a performance bottleneck if complex.

I will just use a limit 👌
It looks like Select rendering time scales linearly with the number of elements ☝️