in reply to Foreach Loop Optimization

/me reaches for large, heavyduty cluestick.

This may be beating a dead horse, because others have pointed this out, but IMHO, it's important that you understand that between your js (onClick), your 800 row table, and your omission of (at least) a "width" value for your table and its cells, you've assigned a lot of computations to your browser.

Just as one example, your <td align="center"> won't let the browser even begin to caluclate where the "center" is until it's evaled the whole table, because it doesn't know how wide the table itself or the cell should be (they're dynamic values when not specified) until it has all the data in hand.

Try, for example, a static 800 row table, on your local machine (pure html, no Perl, no js and using widths); then try again without a width value and with your javascript. I think you'll be amazed at the time required for the browser's rendering engine to do its work, even in the first case, and more so in the second.

In other words, while it would be unfair (oversimplified) to assign all of the time required for you to observe the output to the browser, MUCH of that time is consumed by the browser.

Replies are listed 'Best First'.
Re^2: Foreach Loop Optimization
by upallnight (Sexton) on Aug 01, 2007 at 21:43 UTC
    Amazing!! I didn't think of that.

    I saved the html output from one of the databases (22 columns and 749 rows) to a local file. When I opened that file in Firefox, it took almost the same time to load as the script on the server!

    I gotta clean up my html :(

    How can I speed up the browser parsing when I'm not sure how much data and how long the strings of individual fields are going to be?

    http://uan.no-ip.org

[reply]

      On the theory this is something you'll have to do repetitively, get the lengths of the longest string in each column (ONCE) to get a ballpark idea of what you need for screen-realestate. Make your peace with a need to sidescroll to see all the columns. And recognize that this is rough and ready; different data sets could make hardcoding this way a total bust (though, of course you could build the length determination function into your program :-) but that could easily overwhelm the speedup.)

      Say the results come up this way:

      col len
      1:   11
      2:   4
      3:   80
      4:   27

      In total, you need space for 122 chars per row plus whatever the row label will be (if used). Let's assume no label. So now you can set up your table this way:

      <table width="100%">  #other good practices omitted; beyond the scope 
+here
<thead>
<tr>
<th style="width: 11em;">Col1</th>
<th style="width: 4em;">Col2</th>
<th style="width: 80em;">Col3</th>
<th style="width: 27em;">Col4</th>
</tr>
</thead>
<tbody>
<tr>
<td (whatever styling you want)...</td>
etc.

      [download]

      The tds will inherit their widths from the ths (unless a td ends up with more chars than expected, in which case, different browsers will react in variant ways).

      Hope this helps, but a solid-er answer is probably, "build a better browser."

[reply]
[d/l]

In Section Seekers of Perl Wisdom