does vaadin 7 focus on performance?

Hi,

although i realy appreciate vaadin with respect to the programming paradigm i am still not convinced that vaadin is an appropriate answer for worldwide used applications with high requirements with respect to responsiveness. The ususal problems are

  • to many server roundtrips
  • data throughput
  • high load on java script engines

We are currently implementing a vaadin 6 application as a test appliaction and see all three mentioned aspects.

Is there any hope that vaadin 7 is going to address the different issues? From what i read, layouting is addressed. What about the the other aspects?

We tried to recheck our current application with the vaadin 7 alpha, but for example saw even more server requests than before ( looks like a bug, though )

I really hope getting a positive answer, beause programming with other frameworks like jsf for desktop applications is rather clumsy…

Kind regards,

Andreas

Well there is a few things up that might help out. One is the plans to simplify the layouts a lot to use more standard css solutions to size things instead of doing a lot of size calculations in javascript to make them work as well in browsers like IE6/IE7/Fx2. Support for those browsers are dropped in Vaadin 7 which will give the possibility to do things more effectively. This will reduce the rendering time of pages and simplify theming of applications a lot.

Vaadin 7 Alpha 1 or 2, can’t remember directly which one it was, introduces a new way for server and client side code to communicate which each others. One change was that instead of sending the whole state back and forth all the time and figuring out on the other side what has changed, you can now do method calls from one side to the other with rpc calls. A simple case of this is that the client of a button can now call a clicked -method on the server, instead of sending a variable map with a boolean clicked=true along with variables for caption, stylenames etc.

The changes in the core for that is there, but the communication in the components have not been rewritten to take use of these features yet, so you won’t notice the benefits of reduced communication yet. Only Button and Label has been converted, and I think some of the components are being worked on at the moment. Also I’m not sure if the code is optimized yet, so there might be a bit more communication right now, but it will probably be enhanced during some beta version of V7.

Finally, GWT is now being included into Vaadin package, and will be taken into more use in the future. I think this means that you can do sections of the UI more easily solely on the client side, which means no communication to the server, unless you need it.

Sounds promising. Any idea, when a beta version is available to see the performance improvements?

Just to give you a feedback from my “customer” point of view: Performance - across the different browsers - is an absolute must. As long as this topic is not solved properly all the other features are pretty worthless i am afraid to say.

Btw. my “test” project struggles with tables in combination with inplace editing. If the number of rows exceed about 10-15 switching between different views ( which is a tabbed pane ) shows delays over 2-3s in a Firefox. Since Chrome is ok, the bottleneck is obviously the rendering engine which probably has to deal with quite a number of nested divs in every cell.

Will this also change ( i read something about a complete rewrite of the table in 7.1 ) or do you have some ideas how i could optimize something with the current version?

Cheers,

Andreas

Alpha 3 is out right now. Beta 1 will be out in two weeks and I don’t think much optimization will get into that. final is due in four weeks after the beta. Let’s hope it gets there.

The biggest thing to remember, however, is that how you stack components have a huge impact on rendering performance. Don’t use panels if you don’t really need to, minimize the need of stacked layouts, use CssLayout in places where it can be used, don’t put any components into a table if you can leave the buttons and such outside, etc. etc. Check
this wiki article
for more pointers.

yep, read that article…

Isn’t there any way to handle tables differently? In Swing there is the separation of the model, individual renderers and editors. This separation would allow you to show editors only for focused rows for example, avoiding the overhead for complicated editor widgets in every cell. (I already posted another question concerning a more swing like approach btw. ) From what a read from the manuals this is not possible… Any idea?

Thanks,

Andreas

I typically do not make tables and/or columns editable. (It’s ugly!) Instead I use generated columns. The generated components can display differently depending on if they’re focused or not, and they can handle Property.ValueChangeEvent:s by themselves.

/Anders

what do you mean by “generated columns”. Do you have an example?

Andreas

Generated columns are added using Table.addGeneratedColumn(Object, ColumnGenerator). The column generator can return a Component instance that will then be used in the table. You should however be aware that displaying many such components in a Table is just begging for performance problems, especially if you use complex components (just a Button or TextField per row is usually not a problem).

Could you please show me a sample for a table where only the selected row shows the edit fields… I am not the first looking for such a feature but i did not find a working solution in form of sample code in the forum ( or wherever ) . The TableFieldFactory works fine - setting the read-only property based on the selction - but does not react to selection changes without additional coding. What i really don’t understand is the difference between the factory and the column generator. Seems like more or less the same concepts?

Sorry for stupid questions, btw. , as i was not involved in the coding part with respect to the table stuff in the current project from the beginning. I just started yesterday with firefighting performance problems :frowning:

I agree the table component would make a better fit if it were more like the swing table component, particulary if you are looking at converting existing Java code to Vaadin.