Hi Stephen,
I posted a while back (14th Sept) about the performance of calculating the
number of days between two LocalDates being significantly worse than equivalent
code using YearMonthDay (I've copied the discussion below). Is there any chance
you could take a look and see if there's an optimization? From the discussion,
it looked like exposing the millis value or having an optimised
toDateMidnight() might do the trick.
We're shortly going to be sharing some of our YearMonthDay-based APIs with
another team and I'd like to convert them to LocalDate before we do (as that's
the preferred Joda class; and converting after we've shared the APIs is more
painful). However, the performance hit is preventing us making the move.
Thanks,
Paul
------------------
Paul Field
Global Markets Research IT
Deutsche Bank
---------------------------------------------------
** Paul Field wrote: **
Hi,
My application has to work out the difference, in days, between two dates a
lot. So, I've been investigating the performance of different approaches.
Currently, we're using YearMonthDays and I was thinking of moving us to
LocalDate but I've noticed that the performance is not as good.
There are two approaches:
Approach 1 : the 'obvious' - create a period of type 'days' from the two
dates
Approach 2 : convert to DateMidnight in UTC, then create a period of type
'days' from the two DateMidnights
Here are the results (times in milliseconds are in brackets) together with the
key piece of code:
YearMonthDay - approach 1 (735ms)
new Period(ymd1, ymd2, PeriodType.days()).getDays();
YearMonthDay - approach 2 (234ms)
DateMidnight date1 = ymd1.toDateMidnight(DateTimeZone.UTC);
DateMidnight date2 = ymd2.toDateMidnight(DateTimeZone.UTC);
new Period(date1,date2,PeriodType.days()).getDays();
LocalDate - approach 1 (1328ms)
new Period(ldate1,ldate2, PeriodType.days()).getDays();
LocalDate - approach 2 (531ms)
DateMidnight date1 = ldate1.toDateMidnight(DateTimeZone.UTC);
DateMidnight date2 = ldate2.toDateMidnight(DateTimeZone.UTC);
new Interval(date1, date2).toPeriod(PeriodType.days()).getDays();
FYI: I'm running a simple timing loop that iterates through the calculation
200,000 times (and I do this a few times before the final timing, to
instantiate cached objects, load classes etc). We're running on the Java 5 VM.
The YearMonthDays and LocalDates are just created using the default
constructors.
So, firstly is there any particular reason why converting to DateMidnight is a
bad idea for this algorithm? Next, is there any way to get the performance of
YearMonthDay from LocalDate for this algorithm?
---------------------------------------------------
** Brian O'Neill <[EMAIL PROTECTED]> wrote **
The fastest way to calculate the difference in days is to keep a reference to
the days duraction field, and then call getDifference. Problem is that
LocalDate does not expose the local millis value, which would make such
calculations much quicker.
DurationField daysField = ISOChronology.instanceUTC().days();
...
int differenceInDays = daysField.getDifference(endMillis, startMillis);
The LocalDate class provides limited access to this functionality via a
Property.
int differenceInDays = date.dayOfYear().getDifference(instant);
You can only subtract off a ReadableInstant, however.
---------------------------------------------------
** Stephen Colebourne <[EMAIL PROTECTED]> wrote **
Replying quickly...
A LocalDate and a DateMidnight in UTC ought to be effectively identical,
as they are internally. Hence, converting between them is perfactly
safe, if inconvenient.
However, in fact they use different calculation styles in the Period
constructor. DateMidnight works from milliseconds, LocalDate has to
extract the field values.
Whether any tuning can be done is another matter.
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Joda-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest
