Not Zippy has some good suggestions for increasing perceived speed of
your application - pooling and lazy replication help by creating views
once and reusing them with different backing data.
There are a few other things you can often do to increase performance in
your app -
* Replace ${} constraints with setters where appropriate.
* Defer instantiation of views that aren't needed at app start-up.
* Design your server API to be as light-weight as possible.
* Provide affordances that inform the user that *something* is happening
while the app is waiting for server responses.
* Validate forms on the client wherever possible.
* Measure performance before optimizing. Then you can focus your
attention at the places that optimizations will help most.
If you think of applications that you build as applications rather than
collections of pages or screens you may be able to design and develop
apps in a more modular way.
-Elliot
On Tue, May 1, 2007 at 9:26 AM, Not Zippy wrote:
The application I have written populates 8 slideout panels (10 lines of
data / slideout), 2 floating windows (each with 2 sliders) and 5 (2 pie
2 stackedbar and 1 point) graphs. It takes about 5 seconds to
repopulate. Initial creation times is about 12-20 seconds.
The big hogs are graphs and the slideouts.
Ive also found that resizable text in layouts which are resizable have a
huge performance impact. Pooling and using lazy replication (when
possible) work very well to increase the speed. Reusing instantiated
objects is also a great way to increase performance.
z
On 4/30/07, Jeremy Cowgar < [EMAIL PROTECTED]> wrote: I was reading in
the performance section of the docs and it said
limit the number of screens in your app. How many screens is too
many? I know this is probably a vague question, but I'm speaking of
complex, full window screens accessing data on the web server.
Thanks for any comment,
Jeremy
---=---===-------
Elliot Winard
Sr. Software Engineer
Laszlo Studios
---=---===-------
