Performance is no joking mantter =) 2017-12-13 3:56 GMT+02:00 Lon Varscsak <lon.varsc...@gmail.com>:
> 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 > > > > > >
