Re: Big RPC and long running script error
The long running script error in IE is actually triggered by the number of JS statements executed (by default 5 million). In other browsers the execution time is used. IMHO the IE approach is better because success/failure for an algorithm completely predictable/repeatable based on the complexity of the code and the volume of data/iterations executed between browser events. Unless GWT RPC uses incremental processing for the serialisation my guess is that one should be able to produce a test that repeatable fails on MSIE. I wonder has anyone actually tested? On Jul 7, 6:23 pm, Fred Sauer wrote: > John, > > RPC does try it's best to be fast, but each browser puts its own > restrictions in place for long eval times, and these restrictions change > over time. > > I'd let the user experience guide you. I'd try to start displaying results > to the user as quickly as possible. The user can't absorb 10,000 rows at > once, so why now grab the first 30 or so rows and display those. While the > user is looking at those, you can download additional rows. > > Fred > > On Tue, Jun 30, 2009 at 12:11 PM, John Lonergan > wrote: > > > > > Does the RPC mechanism take any steps to avoid the dreaded long > > running script error for big serialisations and deserialisations? > > > If not then is there anything I can do on the client side to chunk the > > serialisation/deserialisation. > > > I'm shunting 10,000 rows up from the server and back. > > > Surprisingly it seems to perform ok even in IE however I'd like to > > understand the limitations of this RPC technology. > > -- > Fred Sauer > f...@allen-sauer.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
GWT RichTextArea and double line spacing (paragraphs)
When hitting the Return key in a richtextarea we get double line spacing rather than single line spacing. Looking at the generated HTML we find that each CarriageReturn causes a pair of paragraph tags (my text) to be wrapped around the text. Can paragraph insertion be turned off. My users want single line spacing. Suggestions? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Survey - who's doing what
Is there a survey anywhere showing who's using what components/ toolkits. How many people are using just plain old GWT widgets / or some other named toolkit (eg SmartGwt). What folk are using 3rd party toolkits are they mixing basic GWT with toolkit widgets, or just using the toolkit generally. Are folk building new widgets (what/which) or just reusing/agregating other's widgets. Eg google wave - is this build on plain old GWT and/or to what extent have the developers had to extend the basic GWT widget set (eg the GWT grids are pretty basic). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: IE Performance Problems
I am using the SmartGwt grid and stuffing 10K rows into it using their DataSource api wrapped round an RPC. The entire data set gets held client-side. This grid seems to handle loading 10k rows reasonably well. Group/Multiple select may cause the slow running script error on big lists so smartgwt has a configurable 'turn off groupby' at 1000 rows. I don't enable multi select on big lists - is this a really useful feature on a grid with N thousand rows? I haven't yet seen sorting as a problem. Add/remove/edit work fine. On Jun 30, 1:00 am, radcortez wrote: > Hi, > > I'm currently developing a web application using GWT, and i'm having > some performance issues on IE 6 and IE 7. My main requirement is to > have a grid able to fulfill the following operations: > - Pagination > - Sort > - Column Resize > - Add / Remove / Edit rows > - Data Grouping > - Highlighting > > I've looked to some existent solutions like Ext GWT and Smart GWT and > they performed poorly on IE, so i decided to make my own simpler > implementation. > > I began with a simple grid with only data display and started from > that on, to implement those functionalities mentioned above. With each > new implementation, the performance started to degrade a lot, to a > point considered unacceptable to me. > > I know about IE JS engine problems, but is it possible to have a high > performance grid with those features? If yes, do you think i should > stick with some sort of library like Ext GWT or Smart GWT? In my > opinion, the grids offered by those libraries are also slow. Does > anyone have any set of recommendations to develop high performance > widgets in GWT for IE? > > Regards --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Big RPC and long running script error
Does the RPC mechanism take any steps to avoid the dreaded long running script error for big serialisations and deserialisations? If not then is there anything I can do on the client side to chunk the serialisation/deserialisation. I'm shunting 10,000 rows up from the server and back. Surprisingly it seems to perform ok even in IE however I'd like to understand the limitations of this RPC technology. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Browser (IE) hangs when launched a GWT application in a child window
Hi - how did you manage to track and abort outstanding RPC's from the client? Thanks JL On Jun 5, 9:02 pm, gpike wrote: > Hi Maddy, > > We had the same issue. What we found was if the window was closed > while an rpc request was outstanding a port was blocked so subsequent > calls would fail. To fix it we had to track and abort any rpc requests > in a IWindowCloseListener. > > Gordonhttp://devbright.com > > On Jun 5, 12:52 pm, Maddy wrote: > > > > > Hi, > > > My GWT application gets launched in a child browser from another > > parent brwoser. When the user closes the browser, while the GWT > > application is running and when he launches back the application > > again, IE hangs and it is just a blank screen.. > > > This is not happening all the time and it happens occasionally. > > Application works fine in Firefox. > > > Could anybody help me with this, as this is becoming a serious issue.- 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Poor performance for simple query - seems to be in the deserialisation mostly
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" 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 > 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
Re: Poor performance for simple query - seems to be in the deserialisation mostly
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) 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 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 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) > > &
Re: Poor performance for simple query - seems to be in the deserialisation mostly
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 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 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 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 1
Re: Poor performance for simple query - seems to be in the deserialisation mostly
Hi - yep there was a problem in my test program but now that that's
ironed out I'm getting ok'ish performance in 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/ScrollTable/index.html
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 DHTMLX
http://www.dhtmlx.com/docs/products/dhtmlxGrid/samples/loading_big_datasets/5.html
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 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 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 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 you will probably
> > > start to notice the browser groaning under the pressure. Then you can
> > > either f
Re: Poor performance for simple query - seems to be in the deserialisation mostly
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 wrote:
> Hi John,
>
> It sounds like you might be testing this in hosted mode. If so, be
> aware that hosted mode performance, especially where RPC is concerned,
> bears no relationship whatever to deployed performance. 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 you will probably
> start to notice the browser groaning under the pressure. Then you can
> either fetch in batches over RPC or (in the say 500-2000 item range)
> cache all the items on the client and page the grid from that. It
> obviously varies by situation, but RPC data transfer is one thing and
> the HTML box drawing is another.
>
> regards
> gregor
>
> On Dec 19, 2:08 am, John Lonergan wrote:
>
> > I have been evaluating GWT but have come up against a problem I cannot
> > solve/understand.
>
> > I have a little service method that returns a list of 'person data'
>
> > I am finding that whilst the server side take around zero milli-secs
> > to handle the query (100-200 rows) the client is taking seconds before
> > the AsyncCallback.onSuccess() callback fires.
>
> > I am guessing that GWT is taking an age to deserialise the response.
>
> > I cannot afford to wait 2 or 3 seconds to deserialise and then render
> > the response.
>
> > I am unsure what factors might be influencing the performance. Or
> > tuning/settings I might look at.
>
> > I imagine that populating a long grid (well a couple of hundred rows)
> > is something that must be fairly common and that I am doing something
> > wrong, or missing a trick.
>
> > Small sets of 10 rows come back fast enough, but the responsiveness
> > degrades proportionally to the number of rows returned
> > 12 rows 139ms
> > 40 rows 719ms
> > 120 rows 2109ms
>
> > I like the benefits of being able to use the Java programming model
> > and toolset - but unless I can solve the perf issues I must look into
> > alternatives such as generating HTML on the server; ie becoming a more
> > classic JSP/HTML site and I really don't want to do this if I can
> > avoid it.
>
> > Help/advice gratefully accepted.
>
> > See API below.
>
> > John
>
> > My API looks like this..
>
> > // SERVICE INTERFACE
> > public interface ContactService extends RemoteService {
> > public Person[] findContactByName(String namePart);
>
> > }
>
> > // TRANSFER OBJECT
> > public class Person implements IsSerializable {
> > private static final long serialVersionUID = 1L;
> > String personId;
> > String firstName;
> > String lastName;
> > String email;
> > String phone;
>
> > bunch of Getter/Setters - code omited.
>
> > }
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Poor performance for simple query - seems to be in the deserialisation mostly
I have been evaluating GWT but have come up against a problem I cannot
solve/understand.
I have a little service method that returns a list of 'person data'
I am finding that whilst the server side take around zero milli-secs
to handle the query (100-200 rows) the client is taking seconds before
the AsyncCallback.onSuccess() callback fires.
I am guessing that GWT is taking an age to deserialise the response.
I cannot afford to wait 2 or 3 seconds to deserialise and then render
the response.
I am unsure what factors might be influencing the performance. Or
tuning/settings I might look at.
I imagine that populating a long grid (well a couple of hundred rows)
is something that must be fairly common and that I am doing something
wrong, or missing a trick.
Small sets of 10 rows come back fast enough, but the responsiveness
degrades proportionally to the number of rows returned
12 rows 139ms
40 rows 719ms
120 rows 2109ms
I like the benefits of being able to use the Java programming model
and toolset - but unless I can solve the perf issues I must look into
alternatives such as generating HTML on the server; ie becoming a more
classic JSP/HTML site and I really don't want to do this if I can
avoid it.
Help/advice gratefully accepted.
See API below.
John
My API looks like this..
// SERVICE INTERFACE
public interface ContactService extends RemoteService {
public Person[] findContactByName(String namePart);
}
// TRANSFER OBJECT
public class Person implements IsSerializable {
private static final long serialVersionUID = 1L;
String personId;
String firstName;
String lastName;
String email;
String phone;
bunch of Getter/Setters - code omited.
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
