I misunderstood then. I thought the *same* page was slower with Tiles than without. Yes, the javascript would slow it down more. Perhaps you can produce the javascript via the component itself so you don't have to iterrate over the DOM (which is what is taking so long.)
Also, did I understand your earlier response correctly when you said that the *same* was faster if you removed the <f:subview> tags? It sounded like you said it was which would be nice to know. sean On Tue, 11 Jan 2005 11:46:10 -0600, Heath Borders <[EMAIL PROTECTED]> wrote: > 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] >
