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
