But the JS wrappers wouldn't have to go through the rather slow GWT compiler, so in the case of development mode, they would certainly start up faster.
On Jan 18, 11:51 am, Arthur Kalmenson <arthur.k...@gmail.com> wrote: > JS wrappers won't benefit from the GWT compiler, so they would > theoretically be slower. Have you tried without GXT? Is it much > faster? We don't use GXT here and have no issues with dev mode > startup, it's very fast. > > -- > Arthur Kalmenson > > On Tue, Jan 12, 2010 at 10:06 PM, Tercio <terciofi...@gmail.com> wrote: > > Hi! > > > I'm on a Mac 10.6.2 an I have the same issue here. My test as on > > WebKit Version 4.0.4 (6531.21.10, r52686). > > > Using GWT 2.0 and GXT 2.1.0. > > > I think that the problem is the combination of GXT and GWT. I tested > > my application without Hibernate and it is a little faster, but still > > very slow. > > > Maybe as GXT is pure JAVA it needs some parse from the GWT, other > > solutions, like SmartGWT that is just a wrapper it may be faster, I > > don't know. > > > If I compile my project and run it as javascript it gets stunning > > fast! > > > Regards, > > > On Jan 12, 8:22 pm, Chris Lowe <chris.lowe...@gmail.com> wrote: > >> Hi Tim, > > >> It's still conceivable for a circular reference (or at least massively > >> repeated objects) to be at play here. Your response size is 165739 bytes > >> *compressed* size - many identical objects could compress to something > >> relatively small and their expansion could cause issues. Also with > >> Hibernate you most likely won't see a lot of database traffic from repeated > >> objects as subsequent fetch requests will hit the session's level 1 cache. > > >> A quicker test could be to temporarily disable gzip encoding in your > >> browser, for example here are instructions for FireFox: > > >>http://kb.mozillazine.org/Network.http.accept-encoding > > >> With gzip disabled, what size response does Jetty report? > > >> BTW - which browser are you using? > > >> Cheers, > > >> Chris. > > >> <http://kb.mozillazine.org/Network.http.accept-encoding> > > >> 2010/1/12 Tim Mattison <timmatti...@gmail.com> > > >> > That's what I thought originally but I can see that it's only pulling > >> > back > >> > 165739 bytes from the RPC. When I don't return anything it turns out > >> > that > >> > it runs quickly so it obviously must be related to that. > > >> > I'm not using DTOs but where is it trying to fetch the data from if it's > >> > not getting pulled back from the POST? I don't see any traffic to the > >> > database server so it must be doing something weird locally (like a > >> > circular > >> > reference as you suggested). Shouldn't it give up on circular > >> > references a > >> > bit faster than that if that's the case? > > >> > Tim > > >> > On Tue, Jan 12, 2010 at 3:56 PM, Chris Lowe > >> > <chris.lowe...@gmail.com>wrote: > > >> >> Tim, > > >> >> Are you filtering your Hibernate objects or translating them to DTOs (to > >> >> remove dynamic proxies etc) before serialising them? > > >> >> If the answer is no to the above, then you might be falling foul to > >> >> circular references or Hibernate fetching more data than you expect. > >> >> As an > >> >> experiment, is it possible to try hardcoding some of your objects with a > >> >> minimal data set and see how your app performs? > > >> >> Cheers, > > >> >> Chris. > > >> >> 2010/1/12 Tim Mattison <timmatti...@gmail.com> > > >> >>> I changed my debug level from "Info" to "Debug" and got lots of > >> >>> additional output but nothing that looked like it was the culprit. My > >> >>> application runs like this: > > >> >>> 1) onModuleLoad is called, builds the UI, and fires off a GWT-RPC call > > >> >>> 2) The server receives the GWT-RPC call, connects to a Hibernate > >> >>> database, pulls some data (~150K) and sends it to the client > > >> >>> 3) The client receives the response and populates a FlexTable with the > >> >>> data > > >> >>> Between 2 and 3 is where the storm of traffic occurs. With the new > >> >>> debug > >> >>> level I don't really get much more insight since I see that Jetty has > >> >>> sent > >> >>> the response to the browser and that's it. I have breakpoints set on > >> >>> my > >> >>> GWT-RPC callback's onFailure and onSuccess method and it doesn't get to > >> >>> either of those branches until minutes later. Is there somewhere else > >> >>> I can > >> >>> look or something else I can try? > > >> >>> The last message in the log before the storm: > > >> >>> 200 - POST /app/service (127.0.0.1) 165739 bytes > > >> >>> Request headers > > >> >>> Host: localhost:8888 > > >> >>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; > >> >>> en-US; > >> >>> rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 > > >> >>> Accept: > >> >>> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > > >> >>> Accept-Language: en-us,en;q=0.5 > > >> >>> Accept-Encoding: gzip,deflate > > >> >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > >> >>> Keep-Alive: 300 > > >> >>> Connection: keep-alive > > >> >>> Cache-Control: no-cache > > >> >>> Referer:http://localhost:8888/app/hosted.html?app > > >> >>> X-GWT-Permutation: HostedMode > > >> >>> X-GWT-Module-Base:http://localhost:8888/app/ > > >> >>> Content-Type: text/x-gwt-rpc; charset=utf-8 > > >> >>> Content-Length: 175 > > >> >>> Pragma: no-cache > > >> >>> Response headers > > >> >>> Content-Encoding: gzip > > >> >>> Content-Length: 165739 > > >> >>> Content-Type: application/json; charset=utf-8 > > >> >>> Content-Disposition: attachment > > >> >>> The first message after it hits onSuccess and then keeps going at a > >> >>> normal speed: > > >> >>> 304 - GET /app/gwt/standard/images/hborder.png (127.0.0.1) > > >> >>> Request headers > > >> >>> Host: localhost:8888 > > >> >>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; > >> >>> en-US; > >> >>> rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 > > >> >>> Accept: image/png,image/*;q=0.8,*/*;q=0.5 > > >> >>> Accept-Language: en-us,en;q=0.5 > > >> >>> Accept-Encoding: gzip,deflate > > >> >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > >> >>> Keep-Alive: 300 > > >> >>> Connection: keep-alive > > >> >>> Referer:http://localhost:8888/app/gwt/standard/standard.css > > >> >>> If-Modified-Since: Tue, 03 Nov 2009 15:44:06 GMT > > >> >>> Cache-Control: max-age=0 > > >> >>> Response headers > > >> >>> Any help would be great. > > >> >>> Tim > > >> >>> On Tue, Jan 12, 2010 at 3:04 PM, Chris Ramsdale > >> >>> <cramsd...@google.com>wrote: > > >> >>>> Although this smells of a network configuration issue, one suggestion > >> >>>> you could try is to set the log level to Debug or lower. > > >> >>>> Debug->Debug Configurations->GWT->Log level. > > >> >>>> Try that, and let us know if anything suspect is output. > > >> >>>> - Chris > > >> >>>> On Mon, Jan 11, 2010 at 11:56 AM, timmattison > >> >>>> <timmatti...@gmail.com>wrote: > > >> >>>>> I just started using OOPHM on my Mac (10.6.2) and it is very, very > >> >>>>> slow. I've tried all of the recommendations about changing the URL > >> >>>>> to > >> >>>>> include only "localhost" or "127.0.0.1" but I still have to wait > >> >>>>> nearly three minutes for my application to start. > > >> >>>>> The program I'm writing is currently very small and only consists of > >> >>>>> less than 200 lines of code. It does import a JAR that contains > >> >>>>> definitions of a lot of objects and has some dependencies (Gilead, > >> >>>>> Hibernate, GXT) for the server side components but right now I'm just > >> >>>>> using basic GWT components. Does the size of the dependencies and > >> >>>>> included JARs matter? > > >> >>>>> I ask because I notice that as soon as I start the application the > >> >>>>> traffic on port 9997 to and from my loopback interface is pegged at > >> >>>>> 1.5MB/sec in each direction for the entire three minutes the > >> >>>>> application is starting up. I stepped through my code with a > >> >>>>> debugger > >> >>>>> and the client side code gets set up, runs, then there's a three > >> >>>>> minute pause where all of this data goes back and forth, and then the > >> >>>>> server-side code runs. The client and server side code takes less > >> >>>>> than 1 second to finish so I don't think it's a bug in my code. > > >> >>>>> I tried to capture the traffic in Wireshark to figure out what is > >> >>>>> getting sent but it looks like all of the packets are very small (~56 > >> >>>>> bytes) and trying to capture the whole session causes Wireshark to > >> >>>>> crash. > > >> >>>>> Is anyone else seeing this loopback traffic problem? I assumed maybe > >> >>>>> the debugger is communicating my dependencies to the OOPHM plugin but > >> >>>>> my dependencies are nowhere near this large. > > >> >>>>> What other information can I provide to help this get debugged? > > >> >>>>> Thanks, > >> >>>>> Tim Mattison > > >> >>>>> -- > >> >>>>> 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-tool...@googlegroups.com. > >> >>>>> To unsubscribe from this group, send email to > >> >>>>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > >> >>>>> cr...@googlegroups.com> > >> >>>>> . > >> >>>>> For more options, visit this group at > >> >>>>>http://groups.google.com/group/google-web-toolkit?hl=en. > > >> >>>> -- > >> >>>> 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-tool...@googlegroups.com. > >> >>>> To unsubscribe from this group, send email to > >> >>>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > >> >>>> cr...@googlegroups.com> > >> >>>> . > >> >>>> For more options, visit this group at > >> >>>>http://groups.google.com/group/google-web-toolkit?hl=en. > > >> >>> -- > >> >>> 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<google-web-toolkit%2Bunsubs > > ... > > 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 google-web-tool...@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.
