Hi @stuart.clifford again.
We investigated your test case more closely and I could share with you our conclusion.
You use the API from React Data Grid for both demos, and thus you don’t use our API itself - for example, you use rows with an array of object in the settings option, which isn’t possible in our settings (I know, you pass data from rows to data).
After clicking the button value for the first cell is changed by setState. I understand that it is your case.
But it would be better for us to use setDataAtCell. Here is a demo - https://codesandbox.io/s/set-data-at-first-cell-tjrf4?file=/src/index.js - which show that if use our API to this operation Handsontable is pretty fast.
With setState our react wrapper internally uses updateSettings and loadData, which create a new instance. So this is a major reason for performance slow.
Furthermore, you use eval - https://github.com/WranglHQ/handsontable_vs_reactdatagrid/blob/master/src/ParentHandsontable.js#L153 In addition to being very bad practice, it can affect slower code performance.
Although you use our wrapper, all logic is putting in the parent class, and our wrapper is used only for rendering.
However, in your repo - https://github.com/WranglHQ/handsontable_vs_reactdatagrid - you have some weird measuring system, timeouts and reading values from innerHTML. This is not a very robust measuring system.
Finally, I don’t see a memory leak. As we treat all similar issues with high priority please guide on how to replicate the same.
