The values of those methods are calculated every time from the long milliseond value. While they could be cached, I wouldn't want to do that because of the extra memory usage, and in this case it wouldn't help.
As its open source, you are free to hack the source code to try and come up with something faster (eg. inline the calculation into LocalDate if the chronology is ISO). Or if you were brave you could switch to the incomplete and fast changing JSR-310, which stores data differently and probably more optimally. Stephen On 19 February 2011 14:56, Gaurav Arora <[email protected]> wrote: > Hi Stephen, > In my profiling runs I noticed that two parts that used joda-time might have > room for optimizations. Other parts of the application including our own > code has scope for optimization as well but joda-time stood out because it > is heavily used and hence consumes cpu. The object creation isn't a problem > from a heap/memory perspective but from a CPU perspective, the creation of a > new LocalDate costs us CPU, if we had a way to iterate over days between > dates in a more cpu efficient manner, that'd be better. I was just wondering > if any such mechanism existed and I had not overlooked anything. > The other part that came up in my profiling run was the use of > getMonthOfYear(), getYear(), getDayOfMonth() on LocalDate. As mentioned in > the joda-time faq, these are costly operations but ones that cannot be > avoided, anyway that we can access these fields faster, perhaps by bypassing > some of the internal checks? > --Gaurav > > On Sat, Feb 19, 2011 at 20:06, Stephen Colebourne <[email protected]> > wrote: >> >> Hi, >> Object creation is rarely a problem in the modern JVM. The GC is >> optimized for the collection of millions of small, short-lived objects >> like these. >> >> If it is a problem, then you are better off using a long count of days >> directly, but you'll have to rewrite all your code in this case to do >> your own year/month/day calculations if necessary. >> >> I'd recommend some good profiling before making a change though. >> >> Stephen >> >> >> >> On 19 February 2011 11:57, Gaurav Arora <[email protected]> wrote: >> > Hi, >> > I have a list of dates that are exclusions when it comes to processing. >> > A >> > task performing processing may ask for dates that are exclusions between >> > two >> > dates and I need to see if a date is an exclusion or not. The problem is >> > that when I iterate over all dates between two dates I perform this >> > iteration using plusDays(1) on the "from" date provided by the user till >> > I >> > reach the "to" date. This iteration obviously creates a new LocalDate >> > object >> > every time and does not seem to be very efficient. Is there a better way >> > of >> > doing this iteration in performance critical applications? >> > --Gaurav >> > >> > ------------------------------------------------------------------------------ >> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio >> > XE: >> > Pinpoint memory and threading errors before they happen. >> > Find and fix more than 250 security defects in the development cycle. >> > Locate bottlenecks in serial and parallel code that limit performance. >> > http://p.sf.net/sfu/intel-dev2devfeb >> > _______________________________________________ >> > Joda-interest mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/joda-interest >> > >> > >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> Joda-interest mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/joda-interest > > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Joda-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/joda-interest
