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 >
