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
