vaadin performance auditing

Hi,

1) How does the vaadin team ensure that performance does not degrade from release to release, and how do you set your benchmark for what a base performance should be for something like a new widget?

2) What is everyone's take on the theoretical slow down one should experience using vaadin since everything is done on the server side vs doing the same thing on the client side? For example server side validation of a text field would definitely be slower than client side validation, due to the round trips.

Thanks!

Doug Doug: 1) How does the vaadin team ensure that performance does not degrade from release to release, and how do you set your benchmark for what a base performance should be for something like a new widget?

Our build / continuous integration system (TeamCity) makes builds every night (and on demand) and runs some 500+ regression tests. The tests are timed, so we get execution time for each test in milliseconds. TeamCity offers some nice statistics and execution time graphs about the tests. In addition, we follow the Jar size, DefaultWidgetSet size, and theme size.

This does not, by itself, ensure that performance never degrades, but at least we're more aware of any unexpected jumps. Some jumps are expected; for example, the Drag&Drop functionality caused some 20% jump in the size of DefaultWidgetset. It's unfortunate, but what can you do?

There's no particular benchmark for the performance of new widgets.

2) What is everyone's take on the theoretical slow down one should experience using vaadin since everything is done on the server side vs doing the same thing on the client side? For example server side validation of a text field would definitely be slower than client side validation, due to the round trips.

The answer depends mostly on network latency. On a fast network, a 10x jump from some 5 ms to 50 ms would not be noticeable. The problem is, of course, the slow networks, where the slowdown is significant. For example, a typical round-trip time in GPRS or EDGE is around 600 ms, so you'd get a 100x slowdown.

If server-side validation is an issue, you can use, for example, the CS Validation library, which offers a client-side validated TextField.

The slowdown also depends on programming practices. If you're worried about latency, avoid active validation with the immediate mode; only validate on commit clicks, etc.

great thank you all for the input. this is what i was looking for.