1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
---
title: Optimizing Sluggish UI
order: 13
layout: page
---
[[optimizing-sluggish-ui]]
= Optimizing sluggish UI
Is your Vaadin application becoming sluggish? Yes, this can happen - it
is no secret. This can happen for every application, with every
programming language, with every UI library and with all hardware
platforms. Make it a web application and it is not even hard. For end
users this is not acceptable, especially when building applications for
frequent use.
All developers have heard the phrase _premature optimization is the root
of all evil_, coined by software guru
http://www.google.com/search?&rls=en&q=premature+optimization+is+the+root+of+all+evil&ie=UTF-8&oe=UTF-8[Donald
Knuth]. There is a wisdom in that clause. Still I want to motivate you
(Vaadin developer) to read this article, even if you currently have no
performance issues. I'd say it is not that bad to know what will
inevitably make your application slow. You might subconsciously avoid
the worst pitfalls (but still not be subjected to premature
optimization) and avoid optimization task totally.
Resolving performance issues in Vaadin-based applications may be a bit
tricky in some situations. Performance issues are one of the most common
issues why project managers in IT Mill come and disturb our "peace" in
the RnD team. Usually we'll end up modifying the application, not
Vaadin. Vaadin abstracts away the browser environment, and the
abstraction may make it hard to figure out what is the actual cause for
a slow UI.
The first step is to detect whether to optimize the server side or the
client side. You can use all standard profiling tools with Vaadin apps
like Firebug for the client side and JProfiler for the server side. For
a quick look for what is taking so long it is easy to use "?debug" query
parameter in application. It will show you a small floating console in
the browser. Inspecting messages there, one can see server visit time
(includes both network latency and server processing time) and the
actual time spent handling the response in client.
If the problem is on server side, it is most commonly in the back-end
system or how it is connected to Vaadin components. The server side code
of Vaadin is pretty well optimized by the JVM. If the server side is
your problem, I'd bet you will end up optimizing SQL queries. Optimizing
tricks for server side are very similar to any other Java application.
If it is the client side processing that takes a long time, optimizing
methods are more Vaadin specific. There are several tricks one can
perform to optimize the client side processing time. Some of them are
more or less generic to ajax applications in common, others are purely
Vaadin specific tricks. If you belong to the large group of Java
developers who hate browser programming, you don't need to get worried
at this point. Although the processing time is long on client, you will
be mostly modifying the pure server side Java code when optimizing your
application.
[[best-tricks-to-makekeep-your-vaadin-apps-ui-responsive]]
Best tricks to make/keep your Vaadin apps UI responsive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[render-less-components]]
#1 Render less components
^^^^^^^^^^^^^^^^^^^^^^^^^
The most common cause for slow rendering time is that you are rendering
a lot of components.It's easy to forget that the browser is always the
browser, and too much complicated stuff will cause slowness. The
JavaScript engines have been optimized a lot lately, but the actual
rendering is still a bottleneck.
* consider if you can use one component instead of many (eg. instead of
using one label per line, use a label with multiple lines using html :
label.setContentMode(Label.CONTENT_XHTML) )
* hide rarely used features (this also improves usability) when possible
[[try-to-keep-component-tree-simple-flat]]
#2 Try to keep component tree simple (flat)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When component tree (the hierarchy of components, not the 'Tree'
component) gets deeper (more components inside others) the rendering
task gets heavier for browsers. As the growth is more than linear, I
have split this from previous hint. To really show you the importance of
this tip, I made a small example application. Try it at:
http://uilder.virtuallypreinstalled.com/run/deepcomponenttrees/?restartApplication&debug
Tips for keeping the component tree simple:
* Avoid for example using vertical layouts inside another vertical
layouts when possible
* Do you need to extend CustomComponent in your server side composition
or could you just extend some layout? This will result having one
component less in the component tree. You might sometimes be arguing
against this because of architectural reasons (CustomComponent has a
fewer methods than VerticalLayout), but on the other hand Java has
interfaces to deal the issue in a cleaner manner.
* Maybe you have an extra layout inside your Panel or Window (see
setContent method)? This is a common pitfall for Vaadin newcomers.
[[use-the-right-component]]
#3 Use the right component
^^^^^^^^^^^^^^^^^^^^^^^^^^
Some components in Vaadin are just faster to render than others. For
example our standard VerticalLayout and HorizontaLayout have a huge
feature set supporting for example spacing, margin, alignments and
expand ratios. Supporting all these comes with a price of performance
hit. Rendering a lot of simple components into CssLayout (which does not
support all those features), is often several times faster than into the
default layouts.
So favor simpler components in your application if you don't need all
those features. This will be essential in your frequently recycled
server side compositions. So consider if you could use:
* Vertical/HorizontalLayout instead of GridLayout.
* single GridLayout instead of multiple nested
Vertical/HorizontalLayouts.
* CssLayout (available in standard distribution since 6.1) instead of
full featured HorizontalLayout.
* GridLayout (or even FastGrid from FastLayouts incubator project)
instead of Table. Table is meant for displaying tabular data, GridLayout
is meant for laying out components.
In some extreme cases it may be a viable option to build optimized
client side component instead of using pure server side composition. It
is not the easiest path to take as you need to work in browser
environment too, but you then have a full control of what is happening.
With custom client side component one can also more easily optimize also
the data transferred between client and server. Refer to manual for more
information.
[[use-table-efficiently]]
#4 Use Table efficiently
^^^^^^^^^^^^^^^^^^^^^^^^
Table is one of the most optimized component in Vaadin, both server and
client side. Still it is very easy to put both client and server on its
knees with it. Common things to check if you have performance issues
with Table:
* make sure the container used in table loads data lazily from back-end
if you have huge amounts of data
* using the editable mode or ColumnGenerator can make a huge amount of
components to be rendered on client. Especially if table size is
maximized. Consider using lighter components in Table (like putting
complex property editor into PopupView instead of straight to table
cell)
* Don't overuse layouts in table, use CssLayout instead of others when
possible
* Use lazy-loading of rows, don't render all rows at once
* Minimize caching with setCacheRate function, if you have heavy table
body (like large editable table with several columns).
[[avoid-complex-custom-layouts]]
#5 Avoid complex custom layouts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With CustomLayouts it is common to use html tables to build complex
layout. Using html tables as a layout has several drawbacks like heavy
rendering and browser differences. Rendering Vaadin components into a
complex table based dom structure may be much slower than into a simple
div based layout. The core reason for this optimization is the same as
in trick #2 : the rendering is more more expensive in complex dom
structures.
[[use-a-light-theme]]
#6 Use a light theme
^^^^^^^^^^^^^^^^^^^^
The effect of theme may be radical in some cases. Believe it or not, but
I have seen cases where rendering time triples just by using a different
themes. Heavy theme combined with a deep component tree is something
that will really test the speed of browsers rendering engine. For
optimizing theme you can google some generic instructions. Minify,
gzip, use simple (and fewer) selectors, optimize images, use
transparency moderately.
Sizing components can be done in both server side Java code and in
themes css. Both approaches have some good and bad features. Don't use
both methods at the same time for the same component, it may render
improperly and add an extra performance hit.
[[use-generic-component-features-moderately]]
#7 Use generic component features moderately
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All Vaadin components have captions, icons and error indicators. All of
them adds extra burden to client side rendering engine, just like extra
components. As captions, icons and errors are also packed with
surprisingly wide set of features (see ticket
http://dev.vaadin.com/ticket/1710[#1710] in trac), in some cases it may
even be faster to use extra Label or Embedded instead of them.
|
