I've had horrible performance problems rendering even small grids (4x8) in gwt under any mode unless its a fairly small amount of table data was concerned (ie adding a single 5-column row of mixed widgets). The fact that the browser has made such a huge difference indicates that the problem was similar to mine, javascript manipulation of the table dom is slow, which will make no difference regardless of the library you are looking at. I am going to guess that this will be especially true if you are inserting rows using something like a flex table.
We ended up just entirely re-rendinger the table using html (we use gwt for many other things, though), which in our case was considerably faster. If that doesn't seem to work then it might make more sense to render a "maximum" grid initially, but then only show rows to be displayed or just use flex. Nathan On Jan 1, 6:22 am, John Lonergan <[email protected]> wrote: > Dave, > > Hi - it was during an attempt to incrementally extend the grid that I > noticed that the cost of the extenstions on the more functional grids > was exponentially bad for each extension. > > I think the only viable approach is > - a live grid (similar to the DHTMX one or possibly the Live grid in > smart gwt) > or > - ditch GWT and use a plain old server round trip for each grid query, > sort and group operation (which experiment has shown that is an order > of magnitude faster than GWT in IE for a few hundred rows on sorting/ > grouping grids I've seen so far) > > For GWT to be viable we need a set of decent and fast off the shelf > components - I think we're not there yet > The days are gone when I expect my dev team to routinely extend > primitive GUI widgets to make them useful. > > JL > > On Dec 31 2008, 6:11 pm, "Dave LeBlanc" <[email protected]> > wrote: > > > Hi John, > > > You might want to look at using an IncrementalCommand approach to costly > > rendering - that is, you break up an expensive rendering operation into > > chunks and amortize this cost a little - while still maintaining > > interactivity of the browser. > > > This probably wouldn't help your issue if the update really takes 15 > > seconds, but splitting up a 5 second operation into 10 slices, each taking > > 0.5 seconds would probably make the UI appear much more interactive - and > > it's a style people are used to with non-ajaxy apps (the page loading > > incrementally). > > > I second the comment about paging - especially lazy fetching, this can be a > > good way to cut down on the cost of rending all these at once. Looking at > > google reader, I like how they page in older articles as you scroll to the > > end of what they've already loaded. (the reader was also built with GWT). > > Integrating a prefetching approach can add even more interactivity. > > > Finally, you might want to look into augmenting the bulk table stuff with > > your own support for minimal sorting and grouping - if performance is such a > > criteria. > > > Given the constraints of IE, these are probably reasonable approaches. > > > -Dave... > > > On Wed, Dec 31, 2008 at 12:58 PM, John Lonergan > > <[email protected]>wrote: > > > > Firstly thank you all for your continued discussion. > > > > I would really love to start using this technology in a major new app > > > I'm about to start and the reason I'm asking questions / advice is > > > that I need to determine what the limitations are and whether or not > > > this is a viable option for my use cases. > > > > Note that we have an existing front end in .Net with a Java middle > > > tier serving XML to the client. > > > > I have never been happy with this arch and the split of skills, build, > > > test, deployment mechanisms. > > > > The .Net front end only exists to give the user's a richer UI > > > experience - but it's a pain. > > > > I was hoping that GWT would be the enabling technology to ditch > > > the .Net/Windows. > > > > I can see GWT working fine for simple forms or short grids but I must > > > be able to support long grids. > > > > I would not put an explicit grid paging based approach in front of the > > > users. > > > > The point about DHTMLX or other live-grids being a "paging" approach > > > is true from a technical standpoint, but not true from a user- > > > experience viewpoint and that is what really matters. > > > > My eval criteria for grids has been ... > > > - sorting/grouping capability > > > - fast load, which means sub-second rendering of 200 rows of data and > > > no more than 2 or 3 seconds for 2000 rows (this would be worse than my > > > existing .Net solution) > > > > In the case of the second requirement I would accept a 'live grid > > > approach' - which would mean that the requirement could be interpreted > > > as... > > > - "fast load, which means 200ms rendering of first 'page' of data for > > > a set up-to 2000 rows and no more than 200ms for any subsequent page" > > > (200ms is effectively instantaneous from a user perspective). > > > > My feeling from what I've seen is that where IE (all versions) is > > > concerned, none of the currently available widgets can support sorting/ > > > grouping and perform adequately. > > > > --- > > > > The bulk loading stuff (http://google-web-toolkit- > > > incubator.googlecode.com/svn/trunk/demo/BulkLoadingTableDemo/ > > > BulkLoadingTableDemo.html<http://incubator.googlecode.com/svn/trunk/demo/BulkLoadingTableDemo/B...>) > > > looks interesting but there's no sorting/ > > > grouping. > > > > The bulk load API on IE 7 does 2000 rows in <1sec which is great but > > > there's no sort/group. > > > and on chrome I can bulk insert 2000 rows in 200ms which is brilliant > > > except I must use IE. > > > > --- > > > > Re the incubator / scrolltable... > > > > See earlier I used the scroll table as a reference .. > > > >http://google-web-toolkit-incubator.googlecode.com/svn/trunk/demo/Scr... > > > > It's just too slow on IE - worse still the perf actually degrades > > > badly as we add additional batches of rows. > > > > IE7 tests ... > > > 1st set of 100 took 7 secs > > > next set of 100 took 15 secs (ie total 200 rows) > > > thirst set of 100 took 27 secs (ie total 300 rows) > > > > What I was seeing was an exponential degradation in perf for each > > > batch of additional rows. > > > > ---- > > > > Given that all the grids I've looked at performs poorly in IE I expect > > > this will rule out GWT for apps like mine where the main deployment > > > env is IE and where grids of more than a few tens of rows are used. > > > > ---- > > > > From my angle it looks like JavaScript grid functionality is a non- > > > starter because of Microsoft. > > > > The other browsers (particularly chrome) are an order of magnitude > > > faster. > > > > Is there any benefit to Microsoft fixing this? > > > I doubt it. > > > > Wouldn't the success of GWT for corporates actually distract attention > > > from SilverLight? > > > > I'm not a much of a conspiracy theorist but if I were MS then I don't > > > think that fixing IE's obvious perf problems would be high on my list > > > of priorities. > > > > ---- > > > > Note I would love to be proved wrong on the GWT perf thing for grids. > > > > - sorting > > > - grouping > > > - fast (defined above) on IE > > > > ---- > > > > Right now it looks like the only possible contender for me is a Live- > > > grid approach. > > > > Its all so unfortunate - I can get 2000 rows of data into the client > > > with a network round trip, all in less than 100ms but it's taking > > > seconds to render. > > > > Does anyone know of a good sorting/grouping live grid demo that allows > > > a variable number or rows to be inserted (for test purposes)? > > > > Thanks Again folk, > > > > John > > > > On Dec 30, 8:50 am, fin <[email protected]> wrote: > > > > Hi John, > > > > > then have a look at the table stuff in the incubator project. That > > > > contains sortable, pageable, scrollable table solutions which can have > > > > bulk renderers. > > > > It's also worth seeing the gwt mosaic project. It's table solutions > > > > are based on the tables of the incubator project (and seems to be easy > > > > to use but it is still under development). > > > > > Best regards, > > > > Tibor > > > > > On Dec 29, 9:58 pm, John Lonergan <[email protected]> wrote: > > > > > > Hi - I've taken a look at the grids in the incubator and they are > > > > > definitely much faster (200ms in IE7). > > > > > > But those grids are very basic. > > > > > > I need a grid that's a bit more functional .. > > > > > - sorting > > > > > - scrolling > > > > > - fixed non-scrolling header row (i.e.header doesn't scroll with rest > > > > > of grid) > > > > > > Are such features available in a fast grid and are there any examples? > > > > > > Thanks > > > > > > John > > > > > > On Dec 29, 1:18 pm, gregor <[email protected]> wrote: > > > > > > > Hi John, > > > > > > > 1) I concur with your timings on that incubator scroll table demo > > > > > > for > > > > > > FF at 3s, but not on IE at 15s: mine does it in 5s. Suggest > > > > > > something > > > > > > strange about your IE set up?? > > > > > > > 2) The DHTMLX example lazily loads rows on demand using what looks > > > > > > like a scroll listener. Overall table size probably calculated from > > > > > > secondary DB query for num rows and overall height of scroll panel > > > set > > > > > > accordingly. So user gets an impression of the overall size of table > > > > > > and can use scroll bar and/or page ip/down & up/down arrows to > > > > > > navigate it. It only ever fills in the visible portion. Impressive > > > > > > trickery, but IMO the only advantage this has over the more > > > > > > traditional <-prev : next-> button navigation format is user can > > > > > > scroll right down table quickly using the scroll bar handle. But how > > > > > > could user know which records they might hit by doing this? Clever > > > > > > programming maybe but is it good UI design? IMO that is > > > > > > questionable. > > > > > > There are other ways to make sense of large data sets in the UI. > > > > > > > 3) Although it takes 3s for FF and 5s for IE to render the incubator > > > > > > scroll table example for 100 rows, my little test does this in both > > > > > > browsers <0.5s for 200 records, about 0.5s for 500, and about 3s for > > > > > > 2000 in FF, slightly longer for the 2000 in IE. OK, mine is running > > > > > > local and the examples are running over the net, but that doesn't > > > > > > account for all of the massive difference. This should be telling > > > > > > you > > > > > > something: tabular data grids can be complicated things, and people > > > > > > have wide variations in requirements for them, so ready made > > > > > > generalized grid components need shed loads of code to make them > > > > > > configurable for everybody's needs. In most cases if you roll your > > > own > > > > > > component from base GWT widgets you will get blisteringperformance > > > > > > for your own use cases by comparison because you can build it to > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
