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

Reply via email to