Poor Performance with +100 row tables

Phoenix Forum Questions / Help
,
1

I’m currently testing deploying liveview to improve the UI of tables in my project, however i’m running into performance issues when patching unrelated components to the page (such as the new and edit forms).

From what i’ve read about DOM patching, I don’t believe I should be having this much of a delay patching with a relatively small amount of rows on the page (250), which gets increasingly worse the more rows I have on the page.

Theoretically patching the new form component should be lightning fast as it’s not doing anything with the table itself, however the browser performance profile shows it takes almost 250ms to patch, recalculate the styles and layout the page. I’m expecting this to be far worse in production as that dataset is far more complex, though the average displayed row count i expect is around the 250 i’m testing with.

I’ve propped up a demo repository at GitHub - dabaer/liveview-table-test to demonstrate the problem with a generic dataset that seeds 250 randomish rows.

Attempting to patch the new form component with 1000 rows takes about 1-2 seconds on an 8 core Ryzen 7 processor.

Is this just how morphdom operates when patching, scanning through every single row and causing the browser to re-render everything? Or are there performance optimizations I can make on the liveview side?

To clarify as well, I am using temporary assigns with this table, and running with the bare minimum in terms of table features (removing the moveable columns, removing the column sort, removing the dynamic column and data render) does not reduce this repaint time.

2

I’ve only briefly looked at the Github repository, but one of the things that stood out was this particular line here:

Everytime when the layout is changed, this would dispatch a message to the Live View process, triggering a possible re-render each time. I understand that your suggestions indicate a client side issue, but I unfortunately don’t have the expertise in that particular area.

3

Most of the client side performance issues of live view are interaction between morphdom and 3rd party js modules. I see the only thing you use is sortable, try remove that and see what happen.

4

Hmm, that event should only be trigged when one presses the “Default” in the column component though.

5

Ah I did use sortable in the ID for that, however I don’t actually use a 3rd party library for sorting, it’s all apart of the project. I did test prior to adding both the column drag/move and sorting however, and they didn’t add any overhead there.