I am experiencing a significant performance degradation for component adds in Wicket 7.0.0, once the component tree for a page gets reasonably large.
The attached quick start can be used to reproduce the issue. Please note that NUM_ROWS is set to 10,000 to exaggerate the performance degradation as the size of the component tree increases. The same degradation (to a lesser extent) can be viewed with a smaller NUM_ROWS variable.
In Wicket 6.20.0, as the size of the component tree increases, the cost of add() remains relatively constant time-wise. In Wicket 7.0.0, a component add () is much more expensive (and actually makes our internal web application unusable) with form submits taking more than two or three minutes to come back from the server.
Here's some timing examples.
NUM_ROWS = 5000
Wicket 6.20.0 -> ~200 milliseconds of server side rendering (before browser paints HTML).
Wicket 7.0.0 -> ~ 10 seconds of server side rendering
NUM_ROWS = 10000
Wicket 6.20.0 -> ~ 500 milliseconds of server side rendering
Wicket 7.0.0 -> ~ 40 seconds of server side rendering
The attached quickstart can be used to reproduce the issue on your side. My guess is that this has to do with the new component queuing feature that was added as part of Wicket 7.0.0.