On Jun 5, 2009, at 2:00 PM, James wrote:

Try giving this post a read for tips on inserting large amount of data
into the DOM:
http://groups.google.com/group/jquery-en/browse_thread/thread/9889ebd5e10c9122


James,

thank you for the link. The particular thread above deals with inserting a large table at the beginning into the DOM, which is something I do, but is not the pressing issue for me (I am okay with the 5-10 seconds that takes, in my case, though of course bringing that down is a good thing). However, thanks to your link, I was able to follow pointers in the thread and find other pages with comments that may be useful to me.

One of the commentors mentions that he has a template table row that he clone()s to create his table rows. This, interestingly, is exactly the approach I take. What was interesting was that in his case he was attaching the event handlers to the fields in his template and then calling clone(true) so the newly inserted rows also have the event handling cloned. I, however, am using a class selector for the fields to which I attach the event handlers (using livequery). Perhaps if I used his clone(true) approach, things will speed up a bit.

I just created a table with about 300 rows with the same set of fields. It took a good 2-3 minutes to load (since I just wrote a simple PHP for() loop to send the table over), but once loaded its pretty fast (Safari 4). So, its not the browser table+form rendering code that is slow, which is a relief since then I would have to throw out my entire table design or start using pagination.


As for having many form elements, are these elements hidden by
default? Usually the page becomes slower as you add more content on
the page, as it has to keep all that info in memory. And when more
elements are visible, it'll be even slower since more graphical
processing has to be put into that rendering.


Each row has about 7 fields and has an immediate next row associated with it that contains anoter 8 or 9 form elements. This second row is hidden from view, until the user clicks on the primary row, at which time the second row is also displayed.


Depending on what you're trying to achieve, it might be a better
solution to just spread all those rows across several pages.


Yes, that's my final out, if I am unable to get things working faster. I think there is a lot of scope for improvement in my code (the clone(true) might turn out to be one such) given my lack of jQuery (or JavaScript, for that matter!) knowledge.

Thank you, again, for your response,

        --ravi



On Jun 5, 7:13 am, ravi <ravi-li...@g8o.net> wrote:
On Jun 5, 2009, at 1:04 PM, ravi wrote:





Hello all,

a newbie question:

In a web page, I have a table with 300+ rows each with 15 or so form
elements, adding up to 4500+ form elements in that single page. The
table is created and maintained dynamically using jQuery+AJAX. Each
element has a class associated with it and I have used 'livequery'
to attach actions to these classes. Typically the actions are: on
click, display additional information for the row and make all
fields in the row editable, on change, use AJAX to update the change
field values to the DB.

At about 50 rows, the performance is synchronous with user actions.
At 100 rows a small tolerable delay accompanies each user action
(even trivial ones like scrolling). At 200 rows it gets annoying
(again, including simple scrolling). At 300 or more rows it is
unusable.

A clarification: the user actions I am using to test are only clicks,
not changes. i.e., I am not altering fields, so the issue is not AJAX
GET/response.

        --ravi

I have used various tips found online to improve efficiency of my
selectors (e.g: used ID as much as possible). I have also attempted
to minimise superfluous effects, mouseover/out type actions, etc. I
need to consider design improvements. Perhaps load and display form
fields dynamically and incrementally as needed. Also, I can paginate
my table and display the data in chunks (which would break one of
the requirements I was given, but sometimes users need education ;-)).

In the meantime, I was wondering if any of you could advice me on:

(a) what is a legitimate expectation (from HTML, JavaScript and
jQuery perspectives for Firefox 3.x and Safari 3/4) when it comes to
such a large number of form elements. I have done some simple hacks
like commenting out some of the fields and reducing the number to 5
or 6 and that does improve performance a good bit. Is this the path
I should take (which would of course involve a redesign of my UI)?

(b) what newbie errors I might be doing... unnecessary event
bubbling? Poor selector usage? etc. I am puzzled by why even
scrolling slows down, at start of scroll, with jQuery active for the
page.

Any comments, thoughts, suggestions will be deeply appreciated.
Thank you,

   --ravi


Reply via email to