Lon Varscsak created WICKET-6506:
------------------------------------
Summary: Performance issue when large component isn't visible
Key: WICKET-6506
URL: https://issues.apache.org/jira/browse/WICKET-6506
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 8.0.0-M8, 7.2.0
Reporter: Lon Varscsak
Attachments: slownesstest.tar.gz
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 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.
This affects all versions from 7.2.0 and onward.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
