Is GWT high performance with DOM elements?
I want to get some idea of the execution price that I will pay for DOM operations done by GWT. I want to know which operations are "expensive" and which are not, and how I can measure it. I would like to know how I can profile these operations or maybe it is not worth paying attention to these issues at all.
To be more precise, here is a list of use cases that I came across.
1) Use case # 1: you have a widget that changes appearance if some event fades out. Does it make a difference if I delete the old widget and create a new one, or is it better to style the existing widget? In other words, how much is the cost of creating and inserting a new widget into a GWT application? Is there some sort of garbage collector for deleted DOM elements?
2) Use Case # 2: you need to get or store some data from / on the server side. The data can be quite large. Does it make sense to create a custom servlet that will do this in a very simplified way: just accept or print some string instead of making an RPC call with a standard GWT servlet? Is this a good way to improve performance? Your self-employed servlet can be very simple.
3) Use Case # 3: You have a widget that is a long list of other widgets. How can you estimate how many widgets are safe to render for client side performance? I mean, if we were showing 5 million chat messages in the last 5 years, the client side is probably slowing down even if we load items in chunks, thereby limiting server side stress.
4) Use case # 4: what about the execution cost of dom operations, like determining the number of elements inside some container or defining the style of an element? For example, you need to count the number of chat messages. Is this DOM child chat container counting operation so expensive that it is better to implement a separate counter and increment it as new messages arrive (like Java Collections)?
source to share
Use case #1:
Updating style is always recommended rather than remove/add widget
... Updating the style means parsing / recalculating / painting the CSS. Removing / adding a widget will result in DOM and CSS parsing / recalculating / drawing.
Use Case #2:
It really depends on your operation. GWT comes with three server side communication options. Each of them is suitable for different use cases - read here .
a) RPC - Remote Procedure calls
b) RF - Request Factory & Entities
c) Request Builder with self-written Servlet serving up Strings,JSON or Autobean.
Use Case #3:
You have GWT Cell Widgets for displaying big data with minimal DOM operations. If displaying a chat message is a requirement, ask CellList to try with AutoPager on scroll and can be thrown into an asynchronous DataProvider.
Use case #4:
It assumes you are using Java Pojo-enabled Kernel Widgets. Each chat message is a Java Pojo "ChatMessage" instance and based on your RPC call, you get the list and feed it to CellList / CellTable. Why are you counting dom when you can only read "data" with the sizeOf parameter in the list.
You think your project is ahead in the wrong direction. DOM operations are troublesome if your approach to programming is wrong. Go through the GWT samples by downloading the GWT files and execute them by importing them into eclipse.
Performance tuning is the strongest feature of GWT. Given enough experience, you can tweak any performance issues in GWT usingSpeedTracer, Logging, Chrome Dev tools Profiling, GWT Light Weight Metrics, Code Splitting, GWT Compiler Metrics, GWT Closure Compiler, Resource Bundling and the list goes on....
source to share