ok... thank you for your reply Vitali.
:)
On Apr 26, 11:17 pm, Vitali Lovich vlov...@gmail.com wrote:
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
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
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
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 arthur.k...@gmail.com 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
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
On Thu, Apr 16, 2009 at 4:58 AM, Thomas Broyer t.bro...@gmail.com wrote:
On 16 avr, 08:30, Vitali Lovich vlov...@gmail.com 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
On 16 avr, 08:30, Vitali Lovich vlov...@gmail.com 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
On 16 avr, 11:50, Vitali Lovich vlov...@gmail.com wrote:
On Thu, Apr 16, 2009 at 4:58 AM, Thomas Broyer t.bro...@gmail.com wrote:
On 16 avr, 08:30, Vitali Lovich vlov...@gmail.com wrote:
I'm pretty sure that's wrong - inserting things into a table, detached or
not, will still result,
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 what
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
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()
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
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:
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
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
On 16 avr, 10:43, Salvador Diaz diaz.salva...@gmail.com 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
On Thu, Apr 16, 2009 at 12: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
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 Groups
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
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 need to
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
On Thu, Apr 16, 2009 at 1:30 PM, Jason Essington
jason.essing...@gmail.com 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
On Thu, Apr 16, 2009 at 1:27 PM, Pascal zig...@gmail.com 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
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
On Thu, Apr 16, 2009 at 1:22 PM, Jason Essington jason.essing...@gmail.com
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
On Thu, Apr 16, 2009 at 2:15 PM, Arthur Kalmenson arthur.k...@gmail.comwrote:
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
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 vlov...@gmail.com wrote:
On Thu, Apr 16, 2009
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 vlov...@gmail.com wrote:
On Thu, Apr 16, 2009 at 1:27 PM, Pascal zig...@gmail.com wrote:
Creation of individual DOM elements in javascript seems to be
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 zig...@gmail.com 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
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
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
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
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
jason.essing...@gmail.com wrote:
You'll also want to note
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
On 15 avr, 13:51, ytbryan ytbr...@gmail.com 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
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
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
- 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 performing
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
thank you all for your advices... i learn something new again
today. :D
On Apr 15, 11:11 pm, Jason Essington jason.essing...@gmail.com
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
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
41 matches
Mail list logo
