[
https://issues.apache.org/jira/browse/WICKET-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij resolved WICKET-6506.
-------------------------------------
Resolution: Fixed
Fix Version/s: 7.10.0
8.0.0
I've pushed the fix for the performance regression. This speeds up rendering
the table considerably (visible and invisible).
The refresh is still much slower after rendering the table at least once. This
is caused by how ListView works. A ListView creates its items on first render.
Even when the ListView is not visible anymore, these items still need to be
processed during rendering (for example detached) and this takes time. To get
back to the fast state, you have to call ListView.removeAll() when its made
invisible to remove all its children.
> 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: 7.2.0, 8.0.0-M8
> Reporter: Lon Varscsak
> Assignee: Emond Papegaaij
> Fix For: 8.0.0, 7.10.0
>
> 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)
