Vaadin performance issues when compared with Primefaces & ZK

Hello everyone,

I’ve been assigned to evaluate solutions to support a mission critical project. I did a quick test for Vaadin, ZK and Primefaces, but I found a serious memory problem with Vaadin, can someone help me?

My test case is rather simple, just a table that has 10 columns and 2000rows, with 100 concurrent users. Here is my result:

Primefaces: consumed
response time
ZK: consumed
response time
out of memory
and cannot complete the test

After searching the forum I found this (
) and found that mcont might be helpful, after using mcont, the result is improved so that I can finish my test

Vaadin (using mcont): consumed
response time.

However, as you can see
Vaadin uses 6-10 times more memory
than the other two solutions, this is very concerning. There is a lot of pressure on this project so picking the correct technologies is extremely important. As our product is mission critical it will be required to support a large number of users, I want to give Vaadin a fair crack of the whip, so I would appreciate if anyone could give any advice on scaling.


Bean(Item)Container is quite memory hungry due to the amount of metadata it keeps in memory for each item and property, including possible listener lists etc. These could be implemented in a much more memory efficient manner by coupling the classes AbstractBeanContainer, BeanItem and (Nested)MethodProperty a little tighter together.

If its memory usage in your application becomes an issue and you don’t want to use IndexedContainer (which has a much smaller memory footprint), using a custom Container should get you close to the other frameworks in terms of memory usage. It should not be too hard to implement for containers which keep all their data in memory. You can inherit AbstractInMemoryContainer, implement your own Property and Item classes and override some of the container methods with trivial implementations.

If I have extra time at some point, I could try to take some of the ideas from MCont to Vaadin core and try to take them a little further, shaving down memory consumption of metadata as I suggest in the readme. I believe significant improvements are still possible when accepting making some changes to the core classes, although I am not certain whether they would require minor API changes around BeanItemContainer. That is why I preferred to test some of them out in a separate project.

I am somewhat busy at the moment, though, and out of the office at least next week and the beginning of the following week.

Hey Henri,

I really appreciate your reply!

We have tried a few of the techniques you mention but have been unable to get the memory consumption close to the other two.

The problem is at the moment it is in order of magnitude larger than the other solutions. This is very hard to rectify, anyone else having this issue?

Just asking as we are under time pressure for this and our POCs!


Hi, I implemented a custom lazy container optimized to show large collections on beans.
In the attached file you can find the source code of a demo application (vaadin 7.1) with a table showing 2000 beans.

Hope it helps.


DISCLAIMER: it’s in beta, so use and abuse at your own risk. (4.75 KB)

The same container with a bug fix (4.79 KB)

Hey Claudio,

I wanted to personally thank you for your help. The code you provided did help, unfortunately not that much as it was still significantly behind the performance of Primefaces & ZK.

Therefore our management team has cut off the use of Vaadin and it is now a direct shootout between ZK and Primefaces.


Hi Alex S, I am at the same stage here: ZK vs Primefaces. Do you already made your choice? I would appreciate any info regarding this…

Thank you!

Hey Diego,

In the end we decided to go with ZK.

Reason being in our tests we found out that ZK uses slightly more memory than PrimeFaces does ( in this specific test 203MB against 133MB ) however, ZK’s performance and speed was much better than PrimeFaces, in this test (1.5 seconds against 5 seconds).

Speed is more important to us so sacrificing a little bit of memory for around a 250% speed boost overall made sense.

Hope that helps,