Martin is right. It seems like you found a regression in the changes made for WICKET-6021. In general, the performance was increased by those changes, but evidently not in this case. Please create a JIRA issue and attach a quickstart that shows the problem. That should help us debug this regression.
Best regards, Emond On woensdag 13 december 2017 05:39:15 CET Martin Makundi wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
