Hello, I'm hoping someone here can help me. My organization uses Wicket as the framework for a fairly large internal web application.
We have a page that renders a hierarchal data table. It's implemented with a RepeatingView for the table rows, and various WebMarkupContainers for the columns (each column's component for one row gets attached to a new WebMarkupContainer(rv.newChildId()) container). Anyway, the table has about 1,000 rows, and 95% of them are collapsed via JavaScript when the page is rendered. Each top-level table row has a link to expand all of the sub-rows underneath via a small JavaScript function to expand/collapse DOM elements with a certain id. This page has been in use since Wicket 1.4.X, and went through all of the various 5.X.0 and 6.X.0 versions with no issues. However, something changed -- big time -- between Wicket 6.20.0 and Wicket 7.0.0. In Wicket 6.20.0, the server-side page rendering takes about 6s, with another second or two of rendering the HTML in the browser. In Wicket 7.0.0, this increases dramatically to 158 seconds for server-side rendering (with the same one to two second penalty for rendering in the browser). I'm assuming that Wicket's internals changed a lot to support the new Component Queuing functionality. I'm wondering if maybe these changes accidentally degraded performance for large component trees in a single Page (which unfortunately, is our main use-case). A colleague of mine put a bunch of print statements in our code, and found out that some WebMarkupContainer#add(); function calls were taking over 1 second each to complete as the page is rendered (with performance degrading as more and more components are added to the page). Is anyone able to reproduce this issue, or hand any problems like this since upgrading to Wicket 7.0.0? I wanted to check here before trying to put together a Quickstart... Unfortunately, we are in a big crunch for the next few months, so for the time being, we have just reverted to Wicket 6.20.0... (and as a consequence, there's not much time allowed to spend debugging this issue right now). Thanks for anyone's input and help. I really appreciate it. -- Aaron J. Garcia --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
