[
https://issues.apache.org/jira/browse/WICKET-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov updated WICKET-6506:
------------------------------------
Fix Version/s: (was: 7.10.0)
(was: 8.0.0)
8.0.0-M9
> 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
> Priority: Major
> Fix For: 8.0.0-M9
>
> 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
(v7.6.3#76005)
