-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
perf, memory: Improve performance and memory use for large datasets #5927
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 5 commits
73a6b1e
0cc9f19
3ff5df9
a964f41
24710f8
0769660
3620a00
aa518e9
fdc1771
9cf94c1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
import { RowModel } from '..' | ||
import { getRowProto, RowModel } from '..' | ||
import { BuiltInFilterFn, filterFns } from '../filterFns' | ||
import { | ||
Column, | ||
|
@@ -362,14 +362,6 @@ export const ColumnFiltering: TableFeature = { | |
} | ||
}, | ||
|
||
createRow: <TData extends RowData>( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the core I haven't thought all the details through but something like retaining a That way we could also retain the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 to generally recommending people use the same approach for implementing custom features. I considered making things more explicit by adding methods like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This kind of pattern will be useful to think about in the alpha branch though |
||
row: Row<TData>, | ||
_table: Table<TData> | ||
): void => { | ||
row.columnFilters = {} | ||
row.columnFiltersMeta = {} | ||
}, | ||
|
||
createTable: <TData extends RowData>(table: Table<TData>): void => { | ||
table.setColumnFilters = (updater: Updater<ColumnFiltersState>) => { | ||
const leafColumns = table.getAllLeafColumns() | ||
|
@@ -411,6 +403,23 @@ export const ColumnFiltering: TableFeature = { | |
|
||
return table._getFilteredRowModel() | ||
} | ||
|
||
Object.assign(getRowProto(table), { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At one point, we had removed most usages of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It wouldn't be an issue here since it's only called once per table anyway. Your question would apply more to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @KevinVandy beat me to it. I like the idea but am not a big fan of typing the prototype as CoreRow which is not strictly accurate, (and requires us to create these dummy values to keep typescript happy). @mleibman-db did you try making the createRow function into a constructor function, adding the methods directly to the prototype? I haven't tried it myself but intuitively it feels like it should work. Would need to always call createRow with the new keyword I think. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's the wrong type though, isn't it? The prototype shouldn't have the instance properties on it.
I am imagining something approximately like the below. I haven't tried but think it should work, happy to be corrected. The naming would be a bit weird though. const createRow = <TData>(
this: CoreRow<TData>,
table: Table<TData>,
id: string,
original: TData,
rowIndex: number,
depth: number,
subRows?: Row<TData>[],
parentId?: string
) => {
this.id = id
this.original = original
// etc.
}
createRow.prototype.getValue = (columnId: string) => {
// ...
return this._valuesCache[columnId] as any
} elsewhere: const row = new createRow(...) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Anywhere where we are thinking that an alternative would be cleaner, but it's a breaking change, can be reserved for a v9 pr. So far this PR looks mostly good. We don't have to assign dummy vars to the prototype just to satisfy TypeScript. A cast could be acceptable there. If the Object.assign only gets called once, that is negligible and something we don't need to worry about. Direct assignment was a performance improvement in this pr that sped up rendering when creating 10k+ rows. This PR is solving the memory side of that same issue. In conclusion, I'm not worried about this after you explained more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
But I think you can merge the
Personally I am not opposed to using a class if it makes typing easier. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (and just for anyone reading this ... the code snippet in this comment should be using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I was actually agreeing with you that since it's not called many times, it wouldn't be likely to cause issues. I was just trying to explain the likely cause of perf issues - not due to Object.assign(
targetObject, // <-- existing object
{
// new source object which will be garbage collected eventually
},
) If it's used this way in a loop with many thousands of iterations, you can run into perf issues due to garbage collection. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Done. |
||
get columnFilters() { | ||
// Lazy-init the backing cache on the instance so we don't take up memory for rows that don't need it | ||
return (( | ||
this as { _columnFilters?: ColumnFiltersRow<any>['columnFilters'] } | ||
)._columnFilters ??= {}) | ||
}, | ||
get columnFiltersMeta() { | ||
// Lazy-init the backing cache on the instance so we don't take up memory for rows that don't need it | ||
return (( | ||
this as { | ||
_columnFiltersMeta?: ColumnFiltersRow<any>['columnFiltersMeta'] | ||
} | ||
)._columnFiltersMeta ??= {}) | ||
}, | ||
} as ColumnFiltersRow<any> & Row<any>) | ||
}, | ||
} | ||
|
||
|
Uh oh!
There was an error while loading. Please reload this page.