Errai performance issues with tabular data

[hr.stoyanov]

Hi all,

We are seeing some significant performance issues trying to render a grid/tabular with Errai HTML UI and basically structuring the grid as ListWidget of ListWidget. Profiling in Chrome reveals a lot of time spent in Errai data binding, since we bind 3-4 attributes in each grid cell. We are not even using paging. This looks particularly slow on a mobile device. Anyone been there and solved that?

I was thinking of using GWT FlexGrid, which is perhaps not so slow. Alternatively, I was thinking about rendering one big ugly  HTML table snippet serverside, then bind the whole thing once, but this  pretty much defies the whole purpose of Errai HTML UI and is ugly.

Thanks in advance.

[csa]

Hi Hristo,

We know that ListWidget's performance isn't optimal. So, I would expect that a ListWidget of ListWidgets causes problems. Can you share the profiling data with us? It would be good to know where exactly the time is spent in your app. We can definitely try to optimize ListWidget or think about providing a faster alternative.

The last time we profiled ListWidget it was the bean manager (item widget lookups) that slowed down the rendering.

Cheers,

Christian

[hr.stoyanov]

Thanks Christian,

Can you, please provide an email where I can forward some stuff related to this issue.

[magick93]

Hi Hristo

Please share details here too. Other Errai users would really appreciate seeing your findings.

Cheers

[csa]

Hi Hristo,

Can you narrow down your findings so you don't have to share anything proprietary? I am not comfortable looking at anything that can't be made public and this way the whole community could benefit, as Anton pointed out.

Thanks,

Christian

[hr.stoyanov]

... Btw,  you can see an older version at stocks4grab.com,  but the code deployed there is obfuscated,  not sure if it is helpful to run it with Chrome profiler. Try from mobile device too.  If the above info is not enough,  I will try to get better Chrome or FF profile dump.

[csa]

Hi Hristo,

As I assumed above, most time is spent looking up beans (@Templated composites) using the BeanManager (not in Errai's binding or widget logic). Also, you actually have two additional levels of nesting (GroupListWidget (GroupWidget) -> ScreenListWidget (ScreenWidget) -> SymbolListWidget (SymbolWidget)) which as I mentioned above will be slow using ListWidget. How many records are you displaying? Have you confirmed that it's also slow if you remove all your custom logic from @PostConstruct, so it's not in fact a widget-specific problem?

<My impression is that Errai does something very naive /slow with widgets and binding, that can not work  with anything but trivial web apps>

I don't think we're doing anything naive here. We also know of huge applications that use Errai and data binding with good run-time performance. ListWidget is really just a simple built-in option. You can use the data binder API and build your own custom tabular data views.

Another simple thing to try is switching to an IndexedPanel (instead of HTMLPanel) and use this simple patch for ListWidget: https://github.com/dultsch/errai/commit/85ff0d3264e2f5122316760534f82743c562f9e3

This should make it significantly faster. If that helps we can make sure it will be part of the next release.

Cheers,

Christian

[hr.stoyanov]

Thanks Christian,

I have attached a FireFox profiler dump, hopefully more complete - just unzip it and load in FF profiler.

As seen in the screenshot, the grid is 19 rows X 10 columns = 190 cells,the size can vary. This is why it uses nested constructs. Previously, we thought drawing the charts was slowing the rendering, but that is not the case.

I will take a look at the other options, thanks.

[csa]

Looks like your attachment didn't make it through? I've spent a couple of hours profiling this today and saw that almost 100% of the time is spent constructing @Templated beans in Errai UI and IOC but it would be good to see your profiler results to confirm. So, optimizing ListWidget as mentioned above won't improve the situation.

[csa]

OK, thanks. I will add this ListWidget optimization to the next release.

So, to summarize, the main problem is that every row is an IOC managed widget. Creating these instances takes a significant amount of time especially if these instances inject other IOC managed widgets (multiple levels of nesting). I will spend more time profiling and see if I can optimize this.

[hr.stoyanov]

Yes,  this is correct description of the problem. Note that performance goes bad even with small number of components in the table. Let me know if I can help...

[csa]

Both 3.1.0-SNAPSHOT and 3.0.4-SNAPSHOT contain some optimizations now. In Firefox 33, I can now render 500 IOC managed composites (probably more than you want on a single page) in just over one second, using ListWidget and this ItemWidget: https://github.com/errai/errai-tutorial/blob/master/src/main/java/org/jboss/errai/demo/client/local/ComplaintListItemWidget.java

It's definitely worth upgrading but your last statement (slow performance with a small number of items) suggests a different cause entirely.

Cheers,

Christian

P.S. This is just a first update. Happy to optimize more if I find more targets. Any input you have is helpful.

[csa]

I've also noticed two things in your app that will slow down your rendering.

1. Your ScreenWidget, which is used for rows in ScreenListWidget, contains two observers (@Observers methods for ScreenEvent and DetailEvent). This will create two distinct bus subscriptions for every row. I wouldn't do this. It's better to observe these events centrally and then have the table update by manipulating the underlying list.

2. Your templates contain a significant amount of JavaScript that executes on document ready. This will also hurt performance.

I would try to remove both of these for testing purposes.

Cheers,

Christian

[hr.stoyanov]

Christian,

3.0.4-SNAPSHOT and the above changes brought the performance from 20s to about 3s! Thanks and keep optimizing aggressively!