lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
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.

Mike

On Thu, May 21, 2009 at 9:52 AM, Shai Erera <serera@gmail.com> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message