Hi Davide, I'm pretty sure what you're seeing is browser-related, if you are flushing the output periodically from the server: Nat and James have already stated, tables will _likely_ not render until the width of all columns are known ... sometimes the table _will_ progressively render and then "shift about" as wider columns are required in later rows. (You can sometimes check this by waiting a short while so the table has partly downloading and pressing "stop" which usually causes what has been downloaded to display). The actual behaviour tends to be browser-specific and from our tests with IE (5.01SP2) also seemed inconsistent. This is how we got a very satisfatory result:
I'm not sure if this is IE-only behaviour so forgive me if this does not apply to other browsers - but this may serve as a starting point for investigation. CSS2 which I presume is Cascade Style Sheets V2 supports the concept of fixed-width tables, from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie50/html /cheatsheet.asp (Fixed Width Tables section): "HTML tables are normally relatively slow to appear, since browsers calculate the size of each cell in the table before beginning to draw it. When you set the CSS2 table-layout property to FIXED, the browser uses the column-width and row-height information in the first row of the table to lay out the table immediately. Fixed tables render progressively, resulting in a significant speed improvement." We had to use this in an Intranet app that was producing huge tables, i.e. sometimes > 30,000 rows. And, yes, they did "...really, really want to see all the data..." (accountants). Utilising fixed-width tables produced a _significant_ increase in *perceived* speed of page download. The following excerpt was taken from: http://msdn.microsoft.com/workshop/author/tables/tables_overview.asp#layout "The following example shows the use of the Cascading Style Sheets (CSS) attribute, table-layout, to fix the table layout, resulting in faster rendering of the table. Note that the widths need not be set on the TABLE and COL objects. When the width is not specified, the browser looks to the contents of the first row's cells to fix the column widths and, consequently, the table width. <TABLE STYLE="table-layout:fixed" WIDTH=600> <COL WIDTH=100><COL WIDTH=300><COL WIDTH=200> <TR HEIGHT=20> TD>...</TD><TD>...</TD><TD>...</TD> </TR> : </TABLE> The performance gains are significant, especially for large tables. Because the browser does not need to parse through the table once simply to lay it out, the table rows can start to render immediately." HTH, Hue. -----Original Message----- From: Davide Bruzzone [mailto:Davide.Bruzzone@;ngt.com] Sent: 01 November 2002 21:03 To: 'Struts Users Mailing List' Subject: RE: WebLogic/Struts/JSP performance woes... Yes... Again, what's strange is that during my extensive tests/experiments/hair pulling sessions I've actually seen this type of code work (using tables) - There's still a small lag between when the page clears and when the output starts to appear, but output definately starts to appear before the server is done: for (int i = 0; i < myCollection.size(); i++) { out.print("</tr>"); out.print("<td>"); out.print(myData); out.print("</td>"); out.print("</tr>"); out.flush(); } Although by that point, the page that I was using to perform the tests had been tinkered with extensively, so not all the table tags may have been there which might have allowed the browser to render the output sooner. What other tags would you suggest? divs? Cheers... Dave -----Original Message----- From: James Mitchell [mailto:jmitchtx@;telocity.com] Sent: Friday, November 01, 2002 1:55 PM To: Struts Users Mailing List Subject: RE: WebLogic/Struts/JSP performance woes... Also, are you using tables to display? You know.... <table> <tr> <td>inserting data here...... Are you aware that these tables won't be displayed until all text required for this table have been downloaded? (This is true for IE and most others I'm sure) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." - Albert Einstein (1879-1955) > -----Original Message----- > From: Karr, David [mailto:david.karr@;attws.com] > Sent: Friday, November 01, 2002 3:49 PM > To: Struts Users Mailing List > Subject: RE: WebLogic/Struts/JSP performance woes... > > > Is your page precompiled? Are you doing the timing test on your > second display of the page? The first display of a > non-precompiled JSP will take much longer, as it has to generate > and compile the servlet class. > > > -----Original Message----- > > From: Davide Bruzzone [mailto:Davide.Bruzzone@;ngt.com] > > Sent: Friday, November 01, 2002 12:43 PM > > > > I have a page that, for test purposes, is generating a 1760 > > row table (Not a > > gigantic table by any stretch of the imagination). Although I > > don't expect > > our data sets to be this big all the time, I need to make the > > application > > responsive (i.e. If it starts displaying rows immediately - > > while its still > > spitting out other rows - that's fine. What's unacceptable is if the > > application takes a while to do whatever its doing, and > > doesn't generate any > > output until its done, leaving the user with a blank page > > while they wait). > > -- > To unsubscribe, e-mail: > <mailto:struts-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: > <mailto:struts-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
