The point is that GXT isn't a JS Wrapper. It's entirely written in Java. GWT-EXT and SmartGWT are Javascript Wrappers.
Tercio On Jan 18, 2:51 pm, Arthur Kalmenson <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > >> > 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 > >> > <[email protected]>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 <[email protected]> > > >> >>> 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 > >> >>> <[email protected]>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 > >> >>>> <[email protected]>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 > >> >>>>> [email protected]. > >> >>>>> To unsubscribe from this group, send email to > >> >>>>> [email protected]<google-web-toolkit%2Bunsubs > >> >>>>> [email protected]> > >> >>>>> . > >> >>>>> 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 > >> >>>> [email protected]. > >> >>>> To unsubscribe from this group, send email to > >> >>>> [email protected]<google-web-toolkit%2Bunsubs > >> >>>> [email protected]> > >> >>>> . > >> >>>> 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 > >> >>> [email protected] > >> >>> . > >> >>> To unsubscribe from this group, send email to > >> >>> [email protected]<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 [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.
