Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

2017-12-13 Thread Lon Varscsak 
Thanks guys, I filed WICKET-6506.

-Lon

On Wed, Dec 13, 2017 at 2:15 AM, Emond Papegaaij  wrote:

> 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 :
> > > 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 :
> > > > > 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.refreshInternalIteratorIfNeede
> d().
> > > >
> > > > 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
>
>

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

2017-12-13 Thread Emond Papegaaij 
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 :
> > 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 :
> > > > 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

Re: Performance issue (possible bug since 7.2.0…up to and including 8.0.0-M8)

2017-12-13 Thread Martijn Dashorst 
In 7.2 we modified the markupcontainer's storage of its children to
accommodate large numbers of children. The original structure gave adding
children a O(N^2) complexity, so it was changed to become O(1) for N>some
value.

Apparently your use case is not part of our setup and we should see what
happens.

Please file a bug report and we'll look into it

Martijn


On Tue, Dec 12, 2017 at 10:38 PM, Lon Varscsak 
wrote:

> 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
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com