[Question] Table is unresponsive with a lot of entries

Describe the bug
First of all, I am aware of the fact that this table does not mean to implement any kind of virtualization (yet?), but by using e.g. 10.000 entries of data (in combination with filters or other components which might re-render) it is completely unresponsive and exhausts rendering time.
I actually think this might not be classified as a bug, but maybe you can give me a hint on how to handle this situation.

Given the following scenario:
I got a column filter which is any mantine input. I have to track the value (so control the component) because the requirement is to keep the state cross paged. Now, whenever I change the value, I have to update it in my state, whereas the server request is debounced for a few seconds. Due to the fact that the filter values changes (and therefore the column definitions because I might have to change the filtering property etc.) the whole table (including all 10.000 entries) re-renders on every key-up.
I thought about memoizing the columns, but in the end at some point I must (at least partially) re-render the table, for filter visualization, displaying the loading spinner, and possibly more.

Any recommendation on how to handle this? Manually implement virtualizing? Precisely defining a memo comparator?

Basically out of ideas to fix this ...

EDIT: What do you think about offering some kind of row renderer or row memoization? When I e.g. set a filter and therefore implicitly change the column model I do not necessarily want to rerender any row.

To Reproduce
Steps to reproduce the behavior:

Render thousands of entries and e.g. use a filter input whereas the filter change re-renders the table (header).

Expected behavior

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: macOS Sonoma 14.3
• Browser: all
• Version: latest

Additional context

Start by reproducing the reported case in the table component with thousands of entries and a controlled column filter whose server request is debounced. Investigate which table updates occur on each key-up and compare row rendering with header or loading-state updates. Done should be a documented, measurable approach that keeps filtering responsive without breaking filter state or visualization.