The problem turned out to be a javascript function embedded in one of our layouts that iterated through all of the elements in the page.
This obviously causes problems when you have a table with a few hundred rows. As I suspected, it wasn't Tiles; it was the way we were using Tiles. On Tue, 11 Jan 2005 10:41:15 -0600, Heath Borders <[EMAIL PROTECTED]> wrote: > Yeah, i did make the view start in the tile page and it went a lot faster. > > I thought maybe tiles was flushing content to the browser early > somewhere and that maybe this was making things more complicated for > IE. > > However, I was able to put all of the code for the Tiles inside my > Tiled page and the performance was the same, which means its just > something we're doing inside the layouts (hopefully). > > > On Tue, 11 Jan 2005 11:33:53 -0500, Sean Schofield > <[EMAIL PROTECTED]> wrote: > > Heath, > > > > We once had a problem with large tables in IE but this was with > > Struts. The problem seemed to be with the <logic:iterate> tag. We > > resolved it by using a little known Tiles feature called > > TilesController. In our case we were using Tiles but I don't think > > that was really the problem, I think it was the iterrate tag b/c it > > was fine once we switched to the TilesController. > > > > We still have problems with huge tables (5,000 -15,000 rows). So we > > limit the results to 3,000 rows and inform the user. Eventually we > > will replace with one of the faces components for paging through large > > result sets .... > > > > I can't imagine why Tiles would make a difference. Yeah its doing a > > server-side include but so what? The only thing I can think of is > > that with Tiles and JSF you need to use subviews. I'm not expert > > enough on JSF to say what is going on there but my guess is that there > > is more overhead with the use of <subview>. Each row in your 500 row > > table is ultimate bound to some component so any extra steps taken due > > to subview will be magnified greatly. > > > > As an experiment, try making the <view> start in the tile page > > containing your report. See if it runs faster. > > > > I'm interested in hearing about what you come up with. We use Tiles > > extensively in our Struts applications and I'd hate to abandon them in > > order to use JSF. (Although smaller tables is probably the ultimate > > solution here.) > > > > Regards, > > sean > > > > On Tue, 11 Jan 2005 09:19:25 -0600, Heath Borders > > <[EMAIL PROTECTED]> wrote: > > > For some reason, our pages that use Tiles don't perform anywhere near > > > as well as those that don't use tiles. > > > > > > I've been trying to figure out the performance issues, but I'm stuck. > > > > > > I've basically taken all of the code out of our layouts, so that all > > > of the same layouts are getting called, but there is no code in them > > > but the includes I need. > > > > > > The performance problem is really only an issue when we need to render > > > large (500+ rows) tables on a particular page. It takes the page up > > > to a minute to load in IE 6 using tiles, but the load is almost > > > instantaneous without tiles. > > > > > > Obviously, for developer productivity and maintainability, we really > > > love Tiles and want to continue using it, but we can't ignore these > > > performance issues. > > > > > > Does anyone have any ideas? > > > > > > -- > > > -Heath Borders-Wing > > > [EMAIL PROTECTED] > > > > > > > > -- > -Heath Borders-Wing > [EMAIL PROTECTED] > -- -Heath Borders-Wing [EMAIL PROTECTED]
