I guess com.google.gwt.user.datepicker.client.CalendarUtil.getDaysBetween(Date,
Date) was written with datepicker in mind, BTW I've seen some code making
heavy use of that method, and its performance was badly impacted.
Since actual implementation internally instantiates two new dates per every
invocation and then resets the time for each of them, I've simply rewritten
the same logic avoiding date instantiation and time resets, and this gave
me good results.
So I hope CalendarUtil.getDaysBetween() could be enhanced the same way.
Follows an excerpt of a naive test comparing one shot original vs optimized
implementation... clearly this kind of measurement doesn't consider GC time
(mainly induced by original implementation) so I'd consider its results
pessimistic. Nonetheless running it with Chrome 37 on my host, the
execution time of optimized code is almost constantly 25% of original one.
public class Main implements EntryPoint {
@Override
public void onModuleLoad() {
final int count = 100000;
final Date prev = new Date(0);
final Date next = new Date(0);
long optTime = 0;
long origTime = 0;
for (int i = 0; i<count;i++) {
next.setTime(prev.getTime()+1000*60*60*24);
final long startOrig = System.currentTimeMillis ();
final int origResult = CalendarUtil.getDaysBetween (prev, next);
origTime+= System.currentTimeMillis ()-startOrig;
final long startOpt = System.currentTimeMillis ();
final int optResult = getDaysBetween (prev, next);
optTime+= System.currentTimeMillis ()-startOpt;
prev.setTime(next.getTime());
if (optResult!=origResult) {
throw new RuntimeException ("Ouch");
}
}
Window.alert(count+" steps took \noptimized code:
"+optTime+"\noriginal code: "+origTime+"ms");
// GWT.log ("Optimized implementation> "+count+" steps took
"+optTime+"ms");
// GWT.log ("Original implementation> "+count+" steps took
"+origTime+"ms");
}
/**
* {@code CalendarUtil.getDaysBetween()} optimized reimplementation.
*
* @see CalendarUtil#getDaysBetween(Date, Date)
*/
protected int getDaysBetween(final Date start, final Date finish) {
// Extracts midnight time for both dates
final long aTime = (start.getTime() / 1000) * 1000;
final long bTime = (finish.getTime() / 1000) * 1000;
long adjust = 60 * 60 * 1000;
adjust = (bTime > aTime) ? adjust : -adjust;
return (int) ((bTime - aTime + adjust) / (24 * 60 * 60 * 1000));
}
}
Talking about real world code instead, this change practically removed
getDaysBetween effects from CPU profiling charts, while it was originally
one of the main components.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
