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/BulkLoadingTableDemo.html>) > 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/ScrollTable/index.html > > 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 this is obvious when you > > > > play with it because it simply isn't fast enough to deceive the eye. > > > > > > regards > > > > gregor > > > > > > On Dec 29, 9:30 am, fin <[email protected]> wrote: > > > > > > > Hi John, > > > > > > > have a look at the bulk renderer feature of the GWT incubator > project: > http://code.google.com/p/google-web-toolkit-incubator/wiki/BulkTableR... > > > > > andhttp:// > code.google.com/docreader/#p=google-web-toolkit-incubator&s=go... > > > > > > > Best regards, > > > > > Tibor > > > > > > > On Dec 29, 5:32 am, John Lonergan <[email protected]> wrote: > > > > > > > > Hi - yep there was a problem in my test program but now that > that's > > > > > > ironed out I'm getting ok'ishperformancein FF3 and Chrome however > in > > > > > > IE the perf is poor. > > > > > > > > All the time is spent populating the grid / rendering. > > > > > > > > IE is the target deployment platform - they only have IE > installed. > > > > > > > > Have been looking for online samples that are useful for > demonstrating > > > > > > a sort of problem I'm seeing. > > > > > > > > I found this useful demo that allowed me to verify that what I'm > > > > > > seeing re rendering times is not just a result of my dodgy > program. > > > > > > > > > http://google-web-toolkit-incubator.googlecode.com/svn/trunk/demo/Scr... > > > > > > > > I tested by clicking "Add 100 rows" on the Data Manipulation tab. > > > > > > > > The relative timings are ... > > > > > > IE 15 secs > > > > > > FF3 3 secs > > > > > > Chrome 1 sec > > > > > > > > This is consistent with what I see for my grid test. > > > > > > I'm using com.extjs.gxt.ui.client.widget.grid.Grid > > > > > > > > I suspect that the more basic a grid I use, the quicker the > rendering > > > > > > will be. > > > > > > > > However, I assume one can achieve something similar to the 'big > data > > > > > > set example" from DHTMLXhttp:// > www.dhtmlx.com/docs/products/dhtmlxGrid/samples/loading_big_da... > > > > > > Where we fetch the data in chunks on-demand. > > > > > > > > However, I've noticed that the time taken to insert new rows on > the > > > > > > GWT grids I've played with takes longer the more rows are > inserted. > > > > > > > > Are there any good examples of what can be done with big grids > without > > > > > > paging? > > > > > > > > On Dec 22, 2:15 pm, gregor <[email protected]> wrote: > > > > > > > > > Hi John, > > > > > > > > > Yes, compile/browse ought to give you goodperformance. A 200 > Person[] > > > > > > > returned over RPC should enable you to resize and show all of > them in > > > > > > > a Grid within about 0.5s in web mode (it works in > compile/browse too). > > > > > > > Example code below. If it isn't doing so, then something is > wrong with > > > > > > > what you are doing I think, not the RPC layer. > > > > > > > > > regards > > > > > > > gregor > > > > > > > > > public class SandBox implements EntryPoint { > > > > > > > > > private VerticalPanel layout = new VerticalPanel(); > > > > > > > private ScrollPanel scroller = new ScrollPanel(); > > > > > > > private Grid grid = new Grid(1, 5); > > > > > > > > > private Button fireBtn = new Button("Fire", new > ClickListener() { > > > > > > > > > public void onClick(Widget sender) { > > > > > > > GenericListServiceAsync proxy = > > > > > > > GenericListService.App.getInstance(); > > > > > > > proxy.getPeople(new AsyncCallback() { > > > > > > > > > public void onFailure(Throwable caught) { > > > > > > > Window.alert("RPC call failed"); > > > > > > > } > > > > > > > > > public void onSuccess(Object result) { > > > > > > > Person[] people = (Person[]) result; > > > > > > > loadGrid(people); > > > > > > > } > > > > > > > }); > > > > > > > } > > > > > > > }); > > > > > > > > > public void onModuleLoad() { > > > > > > > > > scroller.setHeight("" + (Window.getClientHeight() - > 100)); > > > > > > > scroller.setWidth("100%"); > > > > > > > scroller.add(grid); > > > > > > > > > grid.setBorderWidth(4); > > > > > > > grid.setWidth("100%"); > > > > > > > > > layout.add(fireBtn); > > > > > > > layout.add(scroller); > > > > > > > layout.setSize("100%","100%"); > > > > > > > RootPanel.get().add(layout); > > > > > > > } > > > > > > > > > private void loadGrid(Person[] people) { > > > > > > > > > grid.resize(people.length,5); > > > > > > > for (int i = 0; i < people.length; i++) { > > > > > > > Person p = people[i]; > > > > > > > grid.setWidget(i,0,new Label(p.getPersonId())); > > > > > > > grid.setWidget(i,1,new Label(p.getFirstName())); > > > > > > > grid.setWidget(i,2,new Label(p.getLastName())); > > > > > > > grid.setWidget(i,3,new Label(p.getEmail())); > > > > > > > grid.setWidget(i,4,new Label(p.getPhone())); > > > > > > > } > > > > > > > } > > > > > > > > > } > > > > > > > > > On Dec 22, 11:57 am, John Lonergan <[email protected]> > wrote: > > > > > > > > > > Thanks Gregor > > > > > > > > > > I've hit the Compile/Browse button - I understood that caused > the app > > > > > > > > to run in 'web mode' (as opposed to hosted). > > > > > > > > > > Or do I need to run it in a standalone tomcat to get a perf > boost? > > > > > > > > > > John > > > > > > > > > > On Dec 19, 1:48 pm, gregor <[email protected]> > wrote: > > > > > > > > > > > Hi John, > > > > > > > > > > > It sounds like you might be testing this in hosted mode. If > so, be > > > > > > > > > aware that hosted modeperformance, especially where RPC is > concerned, > > > > > > > > > bears no relationship whatever to deployedperformance. If > so, deploy > > > > > > > > > your example and I think you will be amazed at the > difference. Note > > > > > > > > > building grids, trees etc involves drawing an order of > magnitude more > > > > > > > > > HTML boxes than there are items to display. 200 odd Persons > should > > > > > > > > > display < 0.5s when deployed, but go up to 1000+ and > > > > ... > > > > read more ยป > > > -- Dave LeBlanc <[email protected]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
