Performance issue: `createRow` in tanstack/table-core uses excessive memory

[afreix]

TanStack Table version

v8.21.2

Framework/Library version

tanstack/table-core

Describe the bug and the steps to reproduce it

createRow in row.ts (src) allocates new closures for every row in the table. Each table features also allocate closures for each row. These functions could be defined once on a shared prototype.

We've played around with a few solutions, namely using a WeakMap<Table, rowProto> in order to support a shared prototype for all rows in a given table. The WeakMap appears to be necessary given the dynamic application of table features (i.e. we can't share a row prototype across all table instances).

A JS Heap snapshot shows a memory reduction from 141mb --> 11.6mb in examples/vanilla/basic example with this change. Note: there are a few small issues to fix. We expect it to be productionalizable

It's worth reiterating that users pay the cost regardless of whether they interact with the table, since it happens during initialization.

We'd like to collaborate with the maintainers on productionalizing ideas defined in this commit. Thank you!

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

Reproduction:

• apply this commit and run the examples/vanilla/basic example
• compare JS heap dumps before/after

Attached are screenshots of the before/after that we observed locally:

Before

After

Screenshots or Videos (Optional)

An image of tanStack table initialization closures accounting for 59% of retained memory in our application:

Similar issues:

• Table using insane amount of memory even with virtualisation when scrolling #5696
• When using virtual tables, high memory usage has always been unable to be reduced. #5352

Do you intend to try to help solve this bug with your own PR?

Yes, I think I know how to fix it and will discuss it in the comments of this issue

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

[mleibman-db]

I cleaned up the code a bit and improved how feature mixins are applied so we don't iterate needlessly for each row. See #5927.

[mleibman-db]

This problem can also be easily demonstrated using the grouping demo from the docs - https://tanstack.com/table/v8/docs/framework/react/examples/grouping. Just rendering the table takes up 293 Mb (just the preview IFrame). Grouping by first name jumps it up to 1.5 Gb, and grouping by last name also raises it to 2.5 Gb.