Hi Paul,
Can you download the latest code from SVN and compile it?

There is a new Days class which has a daysBetween() method on it. It
has a specially optimised version (hack) for LocalDate, so give it a
try.

Stephen


On 02/11/06, Paul Field <[EMAIL PROTECTED]> wrote:
>
> 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
>

-------------------------------------------------------------------------
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

Reply via email to