Performance down when more than 400 columns and 50 rows

Tags: #<Tag:0x00007efc60568480>
#1

Hi,

I have a handsontable which bind with dynamic table. And the HOT has formulas on cells, Cell event, afterChange, beforechange events for validation. if the table have more than 400 columns and 50 rows, gets hanged on mentioned events.
its fine when the table is smaller.
var hot = container.handsontable({
data: Data,
rowHeaders: false,
colHeaders: false,
maxCols: dynamicColumns.length,
colHeaders: headerColumns,
columns: dynamicColumns,
colWidths:dynamicColumnsWidth,
fixedColumnsLeft:periodStartIndex-1,
formulas: false,
invalidCellClassName : ‘’,
// readOnly:readOnlyFlag,
hiddenColumns: {
columns: handsontableHiddenColumns
},
fillHandle:
{
autoInsertRow: false
},
manualColumnResize: true,
manualRowResize: true,
cells: function (row, col, prop)
{},
afterChange: function (changes, source) {},
beforeChange: function (changes, source) {}, etc

Please suggest me an idea to reduce time since on every change all the cells are rendering again.

Thanks in advance.

#2

Hi @aswram23

That

is how Handsontable is currently handling changes made on cells. That may change in the future, however, 50 x 400 data should not give you performance issues.

I have a couple of questions to help you get better performance

  • how many columns do you hide with handsontableHiddenColumns
  • what does beforeChange and afterChange do in your project
  • what is ‘etc’ - do you set up any other options
1 Like
#3

Hi @aleksandra_budnik ,
Thanks for the response.

Answers to above questions,

  1. in handsontableHiddenColumns, around 25 columns are hidden.
  2. beforeChange and afterChanges are handling validation on each changes like edit, paste on source.
  3. etc. are nothing but beforeKeyDown, afterRender, beforePaste, afterPaste - there are not much implementation on these events.
    and one more thing in Cell events i am setting Cell Properties(renderer(dropdown), readOnly, className, allowInvalid, type, numericFormat) to specific cells on if conditions.

since you have mentioned 50*400 should be a problem, may i know the max data that can be handled.

#4

Can you share a logic for those hooks? It seems that there’s some heavy lifting for the application.

since you have mentioned 50*400 should be a problem, may I know the max data that can be handled.

Handsontable runs faster for 10k rows and 10 columns than for 10k columns and 10 rows. But it all depends on the logic you’re adding for loading, scrolling, and CRUD operations. A table of 50k rows without any hooks and options implemented should work smoothly on every major browser (especially if you have fixed height defined).

Here https://jsfiddle.net/34c1huzt/ is a demo that loads 1000 rows and 1000 columns which give us 1 000 000 cells in total. This demo should work smoothly on every browser that we support.
If you fill the example with 50k rows table loads instantly https://jsfiddle.net/34c1huzt/1/ so that’s why is important to define where the heaviest operations are taking place and make them lighter.

1 Like
#5

Hi @aleksandra_budnik ,
Thanks for the response.
beforeChange: function (changes, source) {
if (changes != null) {
for (var i = 0; i < changes.length; i++) {
}}}
inside this for block, i have some validation on the cell like parse it and validate, this.getInstance().setDataAtCell(changes[0][0], col1, val, “setZero”).

afterChange: function (changes, source) {
if (changes != null && source == ‘edit’) {}}
inside this block also there are similar validates for some scenarios.

if i simplify the hooks inside before and after change, will i get better performance?
and is this same for cells: function (row, col, prop)
{} also? need to reduce load on this method?

And my version is 6.2.0 will there any improvement in performance is upgrade my version?

#6

Hi @aswram23

what do you do for the afterChange hook?

If you change a lot of data at once (with the setDataAtCell) you may consider using loadData instead. It will make only one call to the renderer.

When it comes to the performance improvement we’ve made some changes in 8.1.0 but that would mainly help to keep the row trimming.

#7