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 do > > > > > exactly what you need it to do, and only what you need it to do. > > > > > > 4) If I wanted to use a ready made component for this I would head > > > > > straight for the new PagingScrollTable in the incubator. Reason being > > > > > that nothing makes into official GWT code unless it works as fast as > > > > > is reasonably possible. GWT makes no compromise on this. What does a > > > > > user care most about: a) how quickly and easily they can get at the > > > > > information they need, or b) how pretty it looks in the screen? > > > > > > 5) If you are using an Ext family grid widget it will definitely run > > > > > slow because there is heaps of Ext framework javascript running as > > > > > well as actual widget code. Ext looks great, but does not compete > > with > > > > > base GWT forperformanceor reconfigurability. > > > > > > 6) Paging *is* the answer to this problem: As you can see from your > > > > > DHTMLX example above, what they do is paging but in a hidden way, > > i.e. > > > > > they try to give the impression that the whole 50,000 rows are > > loaded, > > > > > but of course in reality they are not, and > > ... > > read more »- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
