Re: efficiency of my gwt application

ok... thank you for your reply Vitali. :) On Apr 26, 11:17 pm, Vitali Lovich wrote: > On Sat, Apr 25, 2009 at 10:05 PM, ytbryan 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 some

Re: efficiency of my gwt application

On Sat, Apr 25, 2009 at 10:05 PM, ytbryan 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

Re: efficiency of my gwt application

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? 2) so the rendering of the data is probably the reason why an application looks slow. if the data i want to transfer from serv

Re: efficiency of my gwt application

I think the main question is how it perform in the various IEs. That's the browser you'll see 70% in the wild and 100% of the time in most corporate environments. -- Arthur Kalmenson On Thu, Apr 16, 2009 at 6:23 PM, Jason Essington wrote: > You'll also want to note that 50x50 is a pretty smal

Re: efficiency of my gwt application

No it's not necessarily linear (although I expect that it is actually fairly linear). But I think you're missing the larger point which is that the performance is going to be extremely similar since you're only going to create the grid once with DOM (1.5x isn't that much & as you can see, a faster

Re: efficiency of my gwt application

You'll also want to note that 50x50 is a pretty small test grid compared to what we were talking about here, when the size grows, the time it takes isn't necessarily linear for the DOM object creation. but I've got to say, the results are not what I would have expected on my machine with Saf

Re: efficiency of my gwt application

I dunno, I don't see anywhere near the difference the website claims (average over 5 runs): on Q6600 @ 3.2 GHz FF 3.5 b4: DOM1 65 ms DOM2 65 ms Table 69 ms Inner1: 37 ms Inner2: 39 ms FF 3.0.8 DOM1 86 ms DOM2 73 ms Table 80 ms Inner1: 43 ms Inner2: 42 ms Konqueror (don't have chrome or safari,

Re: efficiency of my gwt application

Sorry, post sent by mistake YO was meant to be You don't even need to trust my testing methodology. :-) On Apr 16, 5:09 pm, Pascal wrote: > A bit in denial are we? Here are raw numbers for you. > > http://www.quirksmode.org/dom/innerhtml.html > > YO > > On Apr 16, 2:14 pm, Vitali Lovich wrote

Re: efficiency of my gwt application

A bit in denial are we? Here are raw numbers for you. http://www.quirksmode.org/dom/innerhtml.html YO On Apr 16, 2:14 pm, Vitali Lovich wrote: > On Thu, Apr 16, 2009 at 1:27 PM, Pascal wrote: > > >> > Creation of individual DOM elements in javascript seems to be pretty slow > >> > (it is a bi

Re: efficiency of my gwt application

Also wanted to add that while innerHTML will get faster only incrementally, the DOM approach actually benefits from the VM getting faster (which is where all the focus is on optimization these days). On Thu, Apr 16, 2009 at 2:26 PM, Vitali Lovich wrote: > > > On Thu, Apr 16, 2009 at 1:22 PM, Jas

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 2:15 PM, Arthur Kalmenson wrote: > > > 1) Do I need to actually draw all 100 000 widgets at once? Can I > > display a portion of the data & defer the rest for a later point in > > time (perhaps doing it in the background) > > You can do that with IncrementalCommand, but

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 1:22 PM, Jason Essington wrote: > > oops, my bad, you are talking about the grid example ... > > This is overly simplified, but ... > > Well lets look at what is happening. every time you create a widget, > you instantiate a javascript object, that object has fields and > m

Re: efficiency of my gwt application

> 1) Do I need to actually draw all 100 000 widgets at once? Can I > display a portion of the data & defer the rest for a later point in > time (perhaps doing it in the background) You can do that with IncrementalCommand, but at the end of the day you're still going to choke the browser each

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 1:27 PM, Pascal wrote: > >> > 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 >> > nat

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 1:30 PM, Jason Essington wrote: > > This is absolutely true, but we are not talking about day to day GWT > development, we are talking about extraordinary circumstances where > some amount of optimization is needed. I'm still not convinced that falling back to raw HTML & i

Re: efficiency of my gwt application

This is absolutely true, but we are not talking about day to day GWT development, we are talking about extraordinary circumstances where some amount of optimization is needed. Under every normal circumstance you would simply develop using widgets, but that becomes impossible if some use cas

Re: efficiency of my gwt application

> > 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. > > I'd

Re: efficiency of my gwt application

oops, my bad, you are talking about the grid example ... This is overly simplified, but ... Well lets look at what is happening. every time you create a widget, you instantiate a javascript object, that object has fields and methods to support widget behavior, so more javascript object ins

Re: efficiency of my gwt application

Which is arguably worse. You'd have to convince me that your app is so super optimized that the memory overhead of using widgets is really costing you. If it's CPU bottlenecked, you'd have to convince me that there's absolutely no room for improvement using caching techniques & whatnot. The wid

Re: efficiency of my gwt application

No widget baggage ... On Apr 16, 2009, at 10:55 AM, Vitali Lovich wrote: > How is this different than building up the HTML structure using > widgets as I mention above? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Group

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 12:04 PM, Jason Essington 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 wou

Re: efficiency of my gwt application

On 16 avr, 10:43, Salvador Diaz wrote: > > 3. when updating the UI, working with hidden (display:none) or, even > > better, detached widgets is faster; sometimes, building a new widget > > "from scratch", populating it and replacing an existing equivalent > > widget might be faster than updatin

Re: efficiency of my gwt application

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 fast

Re: efficiency of my gwt application

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

Re: efficiency of my gwt application

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.

Re: efficiency of my gwt application

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

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 10:46 AM, Ian Bambury wrote: > 2009/4/16 Vitali Lovich > >> >> 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)

Re: efficiency of my gwt application

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 wrote: > 2009/4/16 Vitali Lovich >> >> You seem to be saying tha

Re: efficiency of my gwt application

2009/4/16 Vitali Lovich > > 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

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 7:07 AM, Thomas Broyer wrote: > > > > On 16 avr, 11:50, Vitali Lovich wrote: > > On Thu, Apr 16, 2009 at 4:58 AM, Thomas Broyer > wrote: > > > > > On 16 avr, 08:30, Vitali Lovich wrote: > > > > I'm pretty sure that's wrong - inserting things into a table, > detached or

Re: efficiency of my gwt application

> Do you have any benchmarks showing those advantages ? I wasn't aware > of those 2 facts and I find them quite interesting. I don't, but I do remember some time ago this was discussed (in one of the presentations or maybe on IRC) and it turned out to be a substantial speed increase. I'll see wha

Re: efficiency of my gwt application

On 16 avr, 11:50, Vitali Lovich wrote: > On Thu, Apr 16, 2009 at 4:58 AM, Thomas Broyer wrote: > > > On 16 avr, 08:30, Vitali Lovich wrote: > > > I'm pretty sure that's wrong - inserting things into a table, detached or > > > not, will still result, AFAIK, in DOM operations. > > > ...but DOM

Re: efficiency of my gwt application

On Thu, Apr 16, 2009 at 4:58 AM, Thomas Broyer wrote: > > > > On 16 avr, 08:30, Vitali Lovich wrote: > > I'm pretty sure that's wrong - inserting things into a table, detached or > > not, will still result, AFAIK, in DOM operations. > > ...but DOM operations on a detached tree is much faster bec

Re: efficiency of my gwt application

On 16 avr, 08:30, Vitali Lovich wrote: > I'm pretty sure that's wrong - inserting things into a table, detached or > not, will still result, AFAIK, in DOM operations. ...but DOM operations on a detached tree is much faster because it cannot cause a reflow or repaint (same for display:none DOM

Re: efficiency of my gwt application

> 3. when updating the UI, working with hidden (display:none) or, even > better, detached widgets is faster; sometimes, building a new widget > "from scratch", populating it and replacing an existing equivalent > widget might be faster than updating the existing widget > 4. rendering-wise, try to

Re: efficiency of my gwt application

I'm pretty sure that's wrong - inserting things into a table, detached or not, will still result, AFAIK, in DOM operations. Anyways, if you never add the table to the screen, then it's never attached to begin with. Or do table.removeFromParent(). On Thu, Apr 16, 2009 at 2:23 AM, alex.d wrote: >

Re: efficiency of my gwt application

How do you detach the table from the dom, assuming you can have it's parent with table.getParent() ? On 16 Apr., 04:56, Arthur Kalmenson wrote: > An easy thing you might want to try is to render the table detached > from the DOM. This would ensure that you're not doing any DOM > operations when

Re: efficiency of my gwt application

An easy thing you might want to try is to render the table detached from the DOM. This would ensure that you're not doing any DOM operations when building the table, which is generally very slow. That should be easy to implement if you grab the table's parent. -- Arthur Kalmenson On Wed, Apr 1

Re: efficiency of my gwt application

thank you all for your advices... i learn something new again today. :D On Apr 15, 11:11 pm, Jason Essington wrote: > On Apr 15, 2009, at 8:51 AM,ytbryanwrote: > > > thanks for your reply thomas. for me, there is two cases of slowness. > > > - the rpc is quite slow. i am using it to return a

Re: efficiency of my gwt application

On Apr 15, 2009, at 8:51 AM, ytbryan wrote: > thanks for your reply thomas. for me, there is two cases of slowness. > > - the rpc is quite slow. i am using it to return a few thousand by > eleven column of data(String) There are probably two issues here, one the speed of the RPC, and the

Re: efficiency of my gwt application

> > - the rpc is quite slow. i am using it to return a few thousand by > eleven column of data(String) a) RPC is *much* slower in hosted mode than deployed in web mode. You should time your RPC performance (separately to the table "draw" time) when deployed to find out how it is really perfor

Re: efficiency of my gwt application

Your problem is probably using SmartGWT which is known to be quite slow. On Wed, Apr 15, 2009 at 10:51 AM, ytbryan wrote: > > thanks for your reply thomas. for me, there is two cases of slowness. > > - the rpc is quite slow. i am using it to return a few thousand by > eleven column of data(Strin

Re: efficiency of my gwt application

thanks for your reply thomas. for me, there is two cases of slowness. - the rpc is quite slow. i am using it to return a few thousand by eleven column of data(String) - i have a tabset within my application which i copied from the smartgwt showcase when i click on new tab with google map

Re: efficiency of my gwt application

thanks for your reply thomas. for me, there is two cases of slowness. - the rpc is quite slow. i am using it to return a few thousand by eleven column of data(String) - i have a tabset within my application which i copied from the smartgwt showcase when i click on new tab with google map

Re: efficiency of my gwt application

thanks for your reply thomas. for me, there is two cases of slowness. - the rpc is quite slow. i am using it to return a few thousand by eleven column of data(String) - i have a tabset within my application which i copied from the smartgwt showcase when i click on new tab with google map

Re: efficiency of my gwt application

On 15 avr, 13:51, ytbryan wrote: > hi folks, > > my application has been running very slowly and i would like to know > why. You could try compiling in -style DETAILED (or at least PRETTY) and run a JavaScript profiler (Firebug or IE8 developer tools). GWT comes with a benchmark framework, but

efficiency of my gwt application

hi folks, my application has been running very slowly and i would like to know why. can somebody advise me on what are the common bottleneck that i need to optimise? I am pretty new with gwt. i read the " speed up gwt compiler series http://blog.bazoud.com/post/2008/07/31/Can-I-speed-up-the-GWT-