lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject DateTools performance
Date Thu, 21 May 2009 13:52:55 GMT
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.


View raw message