1) Instead of the Vertifal/HorizontalPanels use UIBinder instead. We almost
never use those panels
but use uibinder and normal html instead.
2) Could you tell a little bit about how you found your performance
problems?
/Flemming
On Sat, Feb 12, 2011 at 4:01 AM, tjmcc18 tjmc...@gmail.com
So to sum it up, for better performance in IE:
- Use uibinder when possible instead of constructing the layout manually
- Use div based widgets instead of VerticalPanel and HorizontalPanel
Does that sound about right? I'll give those a try and see if it speeds
things up. We use a lot of
On Thursday, February 10, 2011 7:20:40 PM UTC+1, Jim Douglas wrote:
Have you profiled your application in Chrome using Speed Tracer?
Also try DynaTrace in IE: http://ajax.dynatrace.com
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
Thanks everyone for the tips. I have found the source of some of my
current problems. One issue is that we were passing around a very
large and complex object in some of our RPC calls. I have heard that
serialization can be slow in IE, and I believe that is the case for
me. I redesigned the
In the past, I have used DynaTrace Ajax
Editionhttp://ajax.dynatrace.com/ajax/en/Default.aspx,
a free IE profiling tool. It has the downside from hitting you with massive
information overload, but I have been able to use it to find array copying
and dom manipulation which, when modified, was
I am working on a GWT application and over time it has become
extremely slow while running in IE7. It still runs very fast in
Firefox3 however. This leads me to believe there must be some GWT
specific programming techniques that while acceptable when running in
Firefox, cause IE to run very
Is the problem in dev or production?
On Feb 10, 2011 12:33 PM, tjmcc18 tjmc...@gmail.com wrote:
I am working on a GWT application and over time it has become
extremely slow while running in IE7. It still runs very fast in
Firefox3 however. This leads me to believe there must be some GWT
The problem is in production mode when running the compiled
javascript.
On Feb 10, 12:35 pm, Jeff Schwartz jefftschwa...@gmail.com wrote:
Is the problem in dev or production?
On Feb 10, 2011 12:33 PM, tjmcc18 tjmc...@gmail.com wrote:
I am working on a GWT application and over time it
If you have any influence over the choice of browser, IE7 should no
longer be used.
But the basic problem is simply the quality of the JavaScript engines
in the various browsers. To see this, go to this page in IE7, IE8,
Chrome, and Firefox and compare the results:
Thank you very much for the information. I have no doubt that the
quality of the javascript engine plays a large role. In my case, I am
using GWT so I have a very limited control over the javascript that is
created. I know the performance of IE may never match Firefox, but is
there any way to
To answer the original question:
Have you found any techniques which enabled you to speed up IE?
The fastest possible code is the code that never gets executed. The
only way to improve performance of your application in IE is to
identify any code that can be done on the server and move it
Have you profiled your application in Chrome using Speed Tracer?
http://code.google.com/webtoolkit/speedtracer/
Even if overall performance is acceptable in Chrome and Firefox, there
are bottlenecks in any application. If you find and optimize those
bottlenecks in Speed Tracer, there's a good
I have not tried speedtracer yet. It is a good idea to improve
performance in Chrome and Firefox as much as possible, as that could
help in IE. I will also review the amount of processing we are doing
on the client, since I agree that could speed things up.
Is IE pretty much a no go for GWT for
Every developer has to weigh the tradeoffs and decide for himself or
herself how to deal with IE. Given market realities, it can be
difficult to take a hard-line position of we don't support IE. But
you can try to direct your users to use modern browsers (WebKit is
best, Firefox is a distant
One place where you might want to start looking is DOM manipulation.
IE is much slower at everything but the DOM can kill your app
performance quicker than anything else.
An example we ran into, creating a table dynamically. Anything that
tries to build and manipulate a table using the DOM (like
Agree with Pascal.
TJ: Maybe you can tell us what your application consists of so that it gets
easier to identify and isolate a DOM manipulation performance problem (if
this is the case). Does it have some kind of table with lots of elements? or
maybe a listbox with lots of entries?
For those
16 matches
Mail list logo