ok... thank you for your reply Vitali. :)
On Apr 26, 11:17 pm, Vitali Lovich <[email protected]> wrote: > On Sat, Apr 25, 2009 at 10:05 PM, ytbryan <[email protected]> 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 <[email protected]> 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 < > > [email protected] > > > > > 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 < > > [email protected] > > > >> > 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 > > > >> <[email protected]> wrote: > > > >> > 2009/4/16 Vitali Lovich <[email protected]> > > > > >> >> 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 [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 -~----------~----~----~----~------~----~------~--~---
