lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: DateTools performance
Date Thu, 21 May 2009 14:16:23 GMT
Yes, please fix :)

I think there may already be an issue open on the single instance /
synchronization / ThreadLocal issue.


On Thu, May 21, 2009 at 9:52 AM, Shai Erera <> wrote:
> How much is DateTools in use? I noticed a couple of potential improvements
> to it, which at least for the benchmark package can improve performance:
> 1. timeToString calls Calendar.getInstance on every call? That's a very
> expensive call to make. Why not store it as a static member? We always call
> it with GMT timezone, and it reads internally the default Locale, so I don't
> think it will change when the JVM is up, unless someone calls
> Locale.setDefault() at some point.
> If we'll do this then we will need to make the method synchronized though
> ... but I don't think that's too critical.
> 2. dateToString calls timeToString(date.getTime()), which then instantiates
> a new Date(). Kind of wasteful, isn't it?
> 3. round(), which is called from timeToString (after creating a Calendarr
> instace) creates another (!) Calendar instance ...
> I found one usage in QueryParser when it parses range queries and some more
> in the test package.
> I don't mind fixing those.
> Shai

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message