> Actually we have some perf tests in our tests suite and it doesn't show any > noticeable degradation between #add() and #queue(). > Although I see now that it just println's the diff, but there is no > assertion: >
Hi Martin, Thank you for your reply. Yes, 158 seconds is slow! Instead of spending time profiling the issue in our application-specific code, I made a quick-start. It turns out that this issue is very easy to reproduce with a vanilla RepeatingView component (as I had suspected). In summary, Wicket 6.20.0 adds 5,000 rows x 6 columns + 5,000 AttributeModifiers [one per row] (i.e. 35,000 add() calls) in about 200 milliseconds. Wicket 7.0.0 takes about 10 seconds to add the same amount of components to the hierarchy. With 10,000 rows x 6 columns + 10,000 AttributeModifiers, (i.e. 70,000 add() calls), Wicket 6.20.0 takes about 500 milliseconds to add all of the components, while Wicket 7.0.0 takes about 40 seconds. In my opinion, this is a huge performance degradation from 6.X.Y to 7.X.Y, and is something that should be looked at. I created an issue in JIRA, attached a quick-start, and marked it as Major issue. In my opinion, this should be moved to Critical or Blocker status though... I'm sure I'm not the only one who adds that many components or attribute modifiers to a page at one time. Thanks for your help. You can reach me here or via e-mail if you need me. Regards, Aaron J. Garcia P.S. I looked at your performance test, and I think it should try and add more than 250 contacts to the page... --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
