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

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

2017-12-12 Thread Martin Makundi 
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
> > >
> >
>

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

2017-12-12 Thread 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
> >
>

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

2017-12-12 Thread Martin Makundi 
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
>

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

2017-12-12 Thread 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