lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Commented: (LUCENE-1653) Change DateTools to not create a Calendar in every call to dateToString or timeToString
Date Tue, 30 Jun 2009 03:41:47 GMT


Shai Erera commented on LUCENE-1653:

In 3.0 when we move to Java 5, we can make Resolution an enum, and then use a switch statement
on passed in Resolution. But performance-wise I don't think it would make such a big difference,
as we're already comparing instances, which should be relatively fast.

How will moving the logic of timeToString, stringToDate and round to Resolution make the code
tighter? Resolution would still need to check its instance type in order to execute the right
code. Unless we subclass Resolution internally and have each subclass implement just the code
section of these 3, that it needs?

> Change DateTools to not create a Calendar in every call to dateToString or timeToString
> ---------------------------------------------------------------------------------------
>                 Key: LUCENE-1653
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Other
>            Reporter: Shai Erera
>            Assignee: Mark Miller
>            Priority: Minor
>             Fix For: 2.9
>         Attachments: LUCENE-1653.patch, LUCENE-1653.patch
> DateTools creates a Calendar instance on every call to dateToString and timeToString.
> # timeToString calls Calendar.getInstance on every call.
> # dateToString calls timeToString(date.getTime()), which then instantiates a new Date().
I think we should change the order of the calls, or not have each call the other.
> # round(), which is called from timeToString (after creating a Calendar instance) creates
another (!) Calendar instance ...
> Seems that if we synchronize the methods and create the Calendar instance once (static),
it should solve it.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message