Haha, sure…I was sure someone was going to argue with me. :P -Lon
On Tue, Dec 12, 2017 at 6:23 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Good find! Sounds like a bug, file to jira? > > 2017-12-12 23:38 GMT+02:00 Lon Varscsak <lon.varsc...@gmail.com>: > > > Okay, so here's the situation, I have a component where an Ajax request > > displays a large table (1000ish rows). It display fast, no problem, not > a > > great use of resources (not paginating), but ignore that for now. I then > > have another Ajax request where I tell the wicket component to not be > > visible and refresh an area. No problem so far (although slightly slow, > > since it's not generating much html, should be faster). Now EVERY Ajax > > request that updates the same area (with the component not in the html) > > takes a long time to respond (half second), even though it should be > > returning in ms, because the html is pretty minimal. > > > > I hooked it up to a profiler and found that it's spending a large amount > of > > CPU time in > > MarkupContainer$MarkupChildIterator.refreshInternalIteratorIfNeeded(). > I'm > > not sure why it would be traversing the component hierarchy of the table > > that's not even visible…but I don't know enough of the architecture of > > wicket to really say…which is why I've come here. :) > > > > I've gone back to 7.1.0 and can confirm that in that version this > "problem" > > does not exist. The Ajax request is as fast as if I've never loaded the > > large table. > > > > So I've attached a link to a Quickstart showing the problem (currently > > configured for 8.0.0-M8, but can be complied down to 7.0.0). When > loading > > the page, first click the refresh link…this will essentially refresh all > > the contents in an Ajax request and give you a sense of how fast it > > _should_ be. The table has not been visible yet, so there have been no > > ListView items created yet. Then click "show table", this will generate > 2k > > dummy rows and redisplay the area. It's obviously slower because it's > > generating 350k of html (but surprisingly fast :P). Then click hide > > table. It takes about the same amount of time to hide the table as it > does > > to show it, which is odd, because the html being regenerated is the same > as > > if there were no table displayed. Then go ahead and click "refresh" and > > you'll see that refreshing a basically empty component is slow because > it's > > referencing all the components in the wicket hierarchy ( > > MarkupChildIterator.refreshInternalIteratorIfNeeded)even though they're > > not > > visible. > > > > Thoughts? I recognize that the first response will be "don't display > 1000 > > rows", but lets ignore that for now. > > > > Thanks! > > > > -Lon > > > > Here's the link to the Quickstart: > > https://www.dropbox.com/s/l0uxsibmh24nsoh/slownesstest.tar.gz?dl=0 > > >
