Ever-increasing delay incurred when adding additional rows to a table

[Mr. Land]

I have a large list of options to offer for selection on a Web page.

Loading an ordinary SELECT element with all the options beforehand
results in it taking far too long to load the page.

I found a technique using an HTML table inside a scrollable DIV to
initially load a small set of the options, then asynchronously fetch
more options using Javascript as the user scrolls to near the bottom
of the DIV. As more "packets" of options are fetched, they are
appended to the HTML table.

This works, but the time required to append the additional options
increases by 2-4 seconds at each fetch.

I'm not sure why, but it appears as if the number of existing rows in
the table is affecting the time it takes for more rows to be added
(I'm always adding the same number of additional rows.)

Any ideas on why this may be happening and how to circumvent it?

Thanks for any help/ideas.

 

[Bart Van der Donck]

I have a large list of options to offer for selection on a Web page.
Loading an ordinary SELECT element with all the options beforehand
results in it taking far too long to load the page.

Then I suppose they already must run in the thousands (not such a good
practice).

I found a technique using an HTML table inside a scrollable DIV to
initially load a small set of the options, then asynchronously fetch
more options using Javascript as the user scrolls to near the bottom
of the DIV.  As more "packets" of options are fetched, they are
appended to the HTML table.

This works, but the time required to append the additional options
increases by 2-4 seconds at each fetch.

I'm not sure why, but it appears as if the number of existing rows in
the table is affecting the time it takes for more rows to be added
(I'm always adding the same number of additional rows.)

Any ideas on why this may be happening and how to circumvent it?

I'm afraid there is not much that javascript can do here. Either
dynamical <td> or <option> will slow down dramatically with that
amount of data. I think there is no other robust way than lowering
your data and spread them across multiple web pages.

 

[The Natural Philosopher]

I have a large list of options to offer for selection on a Web page.

Loading an ordinary SELECT element with all the options beforehand
results in it taking far too long to load the page.

I found a technique using an HTML table inside a scrollable DIV to
initially load a small set of the options, then asynchronously fetch
more options using Javascript as the user scrolls to near the bottom
of the DIV. As more "packets" of options are fetched, they are
appended to the HTML table.

This works, but the time required to append the additional options
increases by 2-4 seconds at each fetch.

I'm not sure why, but it appears as if the number of existing rows in
the table is affecting the time it takes for more rows to be added
(I'm always adding the same number of additional rows.)

Any ideas on why this may be happening and how to circumvent it?

Thanks for any help/ideas.

In a nutshell, Javashite.

What else do you expect when doing operations on large arrays in an
interpreted envirnment with implicit memory management?


I mange to load about 700 select options in less than 2 seconds over a
400kbps link..

 

[Mr. Land]

I have a large list of options to offer for selection on a Web page.

Loading an ordinary SELECT element with all the options beforehand
results in it taking far too long to load the page.

I found a technique using an HTML table inside a scrollable DIV to
initially load a small set of the options, then asynchronously fetch
more options using Javascript as the user scrolls to near the bottom
of the DIV.  As more "packets" of options are fetched, they are
appended to the HTML table.

This works, but the time required to append the additional options
increases by 2-4 seconds at each fetch.

I'm not sure why, but it appears as if the number of existing rows in
the table is affecting the time it takes for more rows to be added
(I'm always adding the same number of additional rows.)

Any ideas on why this may be happening and how to circumvent it?

Thanks for any help/ideas.

I think I may not have expressed what it is I'm doing clearly enough.

Obviously, several thousand rows to a table in one shot is going
to have poor performance.

...which is why I am asynchronously sending a small batch at a time.

The real crux of the question is: why is the time required to add
100 items to a table much longer if the table already has a lot of
rows, versus when it's empty?

I suspect it probably has something to do with space negotiation
within the page, and was hoping there was a way to defer that until
I've finished adding rows.

Thanks anyway for the replies.

 

[Joost Diepenmaat]

I think I may not have expressed what it is I'm doing clearly enough.

Obviously, several thousand rows to a table in one shot is going
to have poor performance.
Yup.

...which is why I am asynchronously sending a small batch at a time.

How are you insterting the rows? Using innerHTML or using the DOM table
methods?

The real crux of the question is: why is the time required to add
100 items to a table much longer if the table already has a lot of
rows, versus when it's empty?

I suspect it probably has something to do with space negotiation
within the page, and was hoping there was a way to defer that until
I've finished adding rows.

The last time I did something like that, the main problem *seemed* to be
both the table column resizing and just the length of the tables. I
"fixed" that by using many smallish tables with a fixed column
size. Which can cause some interesting problems with placing the tables
when cells have wrapped content (since then the tables aren't all going
to be the same size).

This solution probably also has some accessibility implications.

Thanks anyway for the replies.

HTH,

Joost.

 

[Thomas 'PointedEars' Lahn]

The real crux of the question is: why is the time required to add
100 items to a table much longer if the table already has a lot of
rows, versus when it's empty?

I suspect it probably has something to do with space negotiation
within the page, and was hoping there was a way to defer that until
I've finished adding rows.

You have not showed or referred to the code that might be the cause of this
problem.


PointedEars