Use the Duration class instead to fetch the time, although I doubt that's going to improve much.
Of course it's faster to access pre-created objects than creating new ones. Casting is a no-op as far as I know (I can't think of a language right now off the top of my head where it wouldn't be). Well, not really a no-op - it's at most a variable assignment, but those are extremely cheap. On Thu, Apr 23, 2009 at 6:15 AM, denis56 <[email protected]> wrote: > > do you think getting and updating precreated widgets from the table > (getWidget(), casting) is faster than creating them anew? > > one more thing, the gwt documentation mentions that operations with > type long are resource consuming ("Heavy use of long operations will > have a performance impact due to the underlying emulation."), but I am > using long data types extensively (System.currentTimeMillis()) to > apply behavior at some elements (blinking, page reloads). Could this > contribute to noticeable lag? Is there a function that would return > current time as int data type? > > Thanks > > > > On Apr 22, 11:30 pm, Vitali Lovich <[email protected]> wrote: > > On Wed, Apr 22, 2009 at 4:39 PM, denis56 <[email protected]> > wrote: > > > > > His, > > > > > I am seeing above expected performance on my application that displays > > > a table (17 x 17 Flextable, using only GWT widgets) of rows that > > > should be updated (Timer, RPC) at 1 second intervals. While the > > > application targets IE 6 which run somewhat slowly (updates tend to be > > > perfomed about 3 times slower), for sake of fairness I must attest > > > superior performance in Firefox 3. > > > > > Are there common optimizations that help improve speed besides what > > > was recently covered in thread > > > > >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa. > .. > > > > > I have already made sure: > > > - to apply styles only when really needed to avoid browser redraws > > > - to use "table: fixed" to improve table rendering (http:// > > > groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/ > > > 4e7ae69a917236a8/f3fa66ce621e9cb5?lnk=gst&q=layout%3A > > > +fixed#f3fa66ce621e9cb5< > http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...> > > > ) > > > - to use Timer#schedule(1000) instead of timer#scheduleRepeating(1000) > > > to process updates one at a time, as resources free up > > > > > What else could one think of? > > > > > Also, facing some memory leak issues (in IE 6) as there are a lot of > > > objects (Labels, Composites) being created for each row update coming > > > from server. It seems to be solved by reloading page every 30 minutes, > > > but I am wondering if there is a better way to free up browser memory > > > automatically and at certain intervals? > > > > If the structure of your table doesn't change, then pre-create those > labels > > & composites & simply change the data being displayed. Otherwise, at > least > > for IE, innerHTML is significantly faster (although you lose the ability > to > > do widgets & event handling gets more complicated) > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
