Item11140: JS is painfully slow with large numbers of table cells.

Priority: Urgent
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: EditRowPlugin
Reported By: CrawfordCurrie
Waiting For:
Last Change By: CrawfordCurrie
JS is painfully slow with large numbers of table cells.

-- CrawfordCurrie - 21 Sep 2011

It's something to do with making rows draggable; performance is fine when this is disabled.

-- CrawfordCurrie - 22 Sep 2011

By eliminating the use of livequery, I can get IE to behave better, but the row moving stuff is still taking too long.

-- CrawfordCurrie - 22 Sep 2011

Most probably you are trying to initialize behavior for each row individually. How about delegating that to all of the table instead? So livequery isn't watching each row but all of the table surrounding it.

-- MichaelDaum - 07 Oct 2011

I tried it both ways. the problem isn't livequery per se, it's the burden of processing a very large DOM and instrumenting it. A table with all editing features enabled makes FF groan above 1500 cells (chrome is slightly better, IE slightly worse). By disabling row moves you can push that to ~2500. On a fast client, 3000 is possible. But fundamentally, it's the instrumenting of the DOM that's the problem (very few DOM elements are being added; 99% of the work is adding/moving attributes and handlers). With such large tables, composing the HTML and downloading it takes longer than rendering them in the browser.

I think partial loading is the only long term answer. Unfortunately we don't have a solution for this for in-topic tables (it would require careful integration with result sets, for one thing)

-- CrawfordCurrie - 08 Oct 2011

Re-opened - it's still too slow.

-- CrawfordCurrie - 03 Dec 2011

Topic revision: r11 - 08 Dec 2011, CrawfordCurrie - This page was cached on 17 Feb 2017 - 04:28.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License