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 <ser...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
