Updates: We'll continue to support and optimize Cell Widgets as the ideal for rendering large data sets with maximum performance. That's why I'm integrating ElementBuilder into CellTable, as opposed to creating a new widget. As browsers evolve, we'll have to keep Cell Widgets up to date to achieve maximum performance. And it isn't all about performance. The main purpose of ElementBuilder is to allow custom table structures in CellTable, which is a widely requested feature. We may even build a formal expandable rows API on top of it (but no guarantees).
Now, for some interesting performance analysis. As I'm integrating ElementBuilder into CellTable, I'm finding that there is a lot going on under the hood that affects performance. - In isolated testing (non-GWT Javascript), dom manipulation is about the same speed as setting innerHTML, assuming a prebuilt HTML string. However, the cost of building the HTML string makes DOM manipulation a little faster. - However, the assertions and validation checks in the current version of ElementBuilder actually make CellTable slower. The overhead of validating the DOM state is higher than the cost of building the HTML string without any checks. So, it appears that we'll need an option to disable the checks in ElementBuilder and let users take responsibility to ensure they build correct structures (to put ElementBuilder on an equal playing field with the current version of CellTable). I figured it would be a good option, but I didn't realize how important it would be. - In addition, my isolated testing compared the cost of building an HTML string in tiny pieces, which is how ElementBuilder builds strings. However, the current version of CellTable uses templates that include large chunks of static HTML mixed with some variables. As a result, the cost of building an HTML string is currently less than it will be with ElementBuilder. In conclusion, I'm still optimizing to improve performance. On Mon, Jul 11, 2011 at 1:02 PM, Stephen Haberman < [email protected]> wrote: > > > Could you elaborate a bit more on this statement and also how it > > impacts the direction future enhancements for cell widgets in general. > There will be more enhancements to CellTable, but I don't think we'll have any additional breaking changes for a while. Most new features will be optional API additions and the like. The ElementBuilder change is fundamental though. > > I agree that is a good question. > > Even more pessimistically/cynically (so take it with a grain of salt), > is whether modern browsers will eventually be faster (or fast enough) > with per-row/-cell event listeners than CellTable's 1-listener with > manual-dispatching approach. Maybe not with the stock widgets, but > some sort of not-flyweight, but-still-lightweight mini-widgets. > > Granted, CellTable is great for the hear and now (IE/etc.), so > excuse/ignore my musing, especially about something I only > superficially understand. > > Nonetheless, per the breaking change proposal, I'm impressed with your > dedication to API compatibility, and the cleverness of the hack to do > so. > > Any custom CellTable stuff I've done so far as been on the cell > side and not the guts of CellTable itself. In that regard, it sounds > like Cell.render will still take a SafeHtmlBuilder? > Given the perf results you mentioned, should/will Cells eventually use > the ElementBuilder API as well? > Eventually, we will likely integrate ElementBuilder into Cells. If you extend AbstractCell, then we can provide a default render(ElementBuilder) method that defers to the render(SafeHtmlBuilder) method, for backward compatibility. > - Stephen > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
