On Sat, Apr 25, 2009 at 10:05 PM, ytbryan <ytbr...@gmail.com> wrote: > > thank you for all replies. > > i have a few questions: > > 1) JSON data graph with Javascript Overlay -- i can't find example on > this... can someone tell me what is this?
not sure what you mean here. What data graph? Coding basics<http://code.google.com/webtoolkit/doc/1.6/DevGuideCodingBasics.html>is very useful - has a good introduction to overlay objects. > > > 2) so the rendering of the data is probably the reason why an > application looks slow..... never make assumptions about performance. profile your application & get hard numbers. there's several reasons to do this, 2 are extremely important. 1) You are not making guesses - you know exactly where the problem is in your code. 2) You know if your optimizations actually make something faster or slower. > if the data i want to transfer from > server to client is huge..... should i still be using RPC? or is there > a better method? currently, i am using gwt-rpc to transfer 2d array of > string..... It depends. RPC is very good & more importantly, it's extremely convenient to use. If the bottleneck is really the deserialization or the transferred data is too big, you may want to serialize to JSON instead & then just eval on the client side & cast it to an overlay object - that'll definitely be faster in terms of deserialization performance, and may be smaller in terms of transfer size. However, the server impact is much harder to estimate - there are too many factors. It could improve performance, make it worse, or have no impact. > > > 3 can someone explain to me why the need of JSON and XMl > serialisation? besides the need to communicate with non-java server? Not sure what you mean here. JSON & XML data sources are very common on the internet. Many web-apps use services & data stores on third-party servers (i.e. Google maps). Since google likes people building things on top of their services, building it into GWT is nice (although adding this functionality is not difficult since the browsers support it natively). > > > > thanks...... > > > On Apr 16, 6:04 pm, Jason Essington <jason.essing...@gmail.com> wrote: > > Their reasoning was that object instantiation was orders of magnitude > > slower than simply building the HTML. in some cases even building HTML > > on the client was too slow, so they would shuttle it off to the > > server. The application would decide at runtime which way was faster, > > and use the fastest method. > > > > For a quick rendering test, you can try to create a 100x100 table > > (grid) using GWT widgets, and then do the same thing using > > setInnerHTML() (with a string that ultimately has the same DOM) ... > > you'll find that while the setInnerHTML() is nearly instantaneous, the > > creation of the widgets takes some time. > > > > Creation of individual DOM elements in javascript seems to be pretty > > slow (it is a bit faster in the new generation browsers ff3, Safari4 > > and chrome) but setInnerHTML() doesn't create those elements in > > javascript, it is done natively in the browser and thus is much faster. > > > > Another technique that I use when populating multiple "cells" that > > have the same HTML structure is to embed a hidden "template" in the > > host page. This template has all of the HTML structure, but no > > content. I have GWT find and store the elements that will be bound > > with data (traverse the DOM of the template only once) from my model > > objects, then when I need to fill the cells, I setInnerText, or > > setInnerHTML() on each of the found elements from the template, and > > once the databinding is complete, perform a getInnerHTML() on the > > template, and use that string to setInnerHTML() on the "cell" ... this > > works great as there is really no DOM object creation happening in > > Javascript, and is considerably faster than building up the widgets > > individually. > > > > -jason > > > > On Apr 16, 2009, at 9:44 AM, Vitali Lovich wrote: > > > > > Can you point out the relevant segments within the presentation? I > > > skimmed through some parts, & it seemed like they went for just > > > building the raw HTML on the client side (hence the reason they > > > transfer HTML from the server). > > > > > Also, they're presentation is for 1.4, so they're reasons might not > > > be relevant any more (especially since 1.5 included a lot of > > > improvements & 1.6 introduced improvements with the event subsystem). > > > > > Also, they don't seem to be using deferred binding for some reason > > > to get around > > > > > On Thu, Apr 16, 2009 at 11:19 AM, Jason Essington < > jason.essing...@gmail.com > > > > wrote: > > > You might want to tell the Lombardi Blueprint guys that ... as it > > > turns out, they discovered in the development of their application > > > that you are mistaken on all points. > > > > > Feel free to watch their presentation from Google I/O last year if > > > you'd like to check my references: > > >http://sites.google.com/site/io/using-gwt-to-build-a-high-performance. > .. > > > > > -jason > > > > > On Apr 16, 2009, at 9:10 AM, Vitali Lovich wrote: > > > > >> I dunno about that one two fronts: > > > > >> 1) All the same DOM elements still have to be created. This would > > >> only help if you have such a slow JS engine in your browser that > > >> running the DOM manipulations in Javascript is so slow that it > > >> outweighs the cost of actually performing the manipulations (which > > >> I believe would always be done in native code anyways) > > > > >> 2) You're transmitting more data across the pipe - the extra > > >> markup is unnecessary data & can bloat your transfer by quite a > > >> bit, slowing down your responsiveness. > > > > >> 3) It's not scalable. Your moving rendering code from the client > > >> to the server which places more load on the server. Performing > > >> string concatenations also isn't cheap (unless you build your own > > >> string class that offers fast concatenation through pointers to > > >> strings & perform all the stream output yourself). Obviously if > > >> the number of users is limited you don't care. > > > > >> So all 3 reasons together (mainly 1 & 2 though), I don't see how > > >> that would help. Obviously some hard numbers are needed as all > > >> this is just hand waving guesses of expected behaviour. > > > > >> On Thu, Apr 16, 2009 at 10:55 AM, Arthur Kalmenson < > arthur.k...@gmail.com > > >> > wrote: > > > > >> Just asked a GWT wizard on IRC and turns out I was incorrect. He > > >> offered an interesting alternative solution. Build the table as HTML > > >> and send that down instead. > > > > >> -- > > >> Arthur Kalmenson > > > > >> On Thu, Apr 16, 2009 at 10:46 AM, Ian Bambury > > >> <ianbamb...@gmail.com> wrote: > > >> > 2009/4/16 Vitali Lovich <vlov...@gmail.com> > > > > >> >> You seem to be saying that: > > > > >> >> tree t = new tree() > > >> >> t.addItem("abc"); > > >> >> t.addItem("def"); > > >> >> RootPanel.get().add(t); > > > > >> >> will have fewer reflows than > > > > >> >> tree t = new tree() > > >> >> RootPanel.get().add(t) > > >> >> t.addItem("abc") > > >> >> t.addItem("def") > > > > >> >> According to you (at least from what you've said so far) is that > > >> the 1st > > >> >> snippet will cause 1 DOM reflow whereas the below snippet will > > >> cause 2, > > >> >> which isn't actually the case AFAIK. Both will only cause 1 & > > >> will be > > >> >> equally fast. > > > > >> > I think you are both right, depending on the browser you are in. > > >> > FF2 (IIRC) will rerender during a sequence where most other > > >> browsers won't. > > >> > I don't know when it decides to do that, but most other browsers > > >> would be > > >> > still displaying your splash screen while FF2 has hidden it and > > >> has stuff > > >> > dancing about on the screen. > > >> > OTOH, if you widget is not attached and you are setting > > >> percentage heights > > >> > and widths, for example, they will fail. > > >> > Ian > > > > >> >http://examples.roughian.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 -~----------~----~----~----~------~----~------~--~---
