While profiling we came across a hotspot where we calculate the calendar day difference between some dates. Searching the net has produced a few suggestions for other ways to to do this correctly, but not really any good way to do this correctly And fast!
So for example we have something that takes 2 Date parameters, constructs a couple of gregorian calenders with fixed time zones, zeros out the time portion, adds an hour to avoid daylight saving time issues, then compare the ms differnce. Works, but seems a bit slow...
I haven't run the code, but I think you are trying to get the number of days difference between 2 dates. A number like 60 days, or even 1000 days would be returned?
I should preface this by saying I haven't used the Calendar/Date classes that much. One thing you could try although it would involve using deprecated classes. Use methods like Date.getDay(), Date.getMonth(), Date.getHours() etc. This would make it so you don't have to create the 2 Calendar objects and call the set methods. The downside is that you will use deprecated methods. Also, I am not sure if it will be faster or not. You would have to profile and see where the bottleneck is in your current code, and the changed code. Do you know what in your code is the most costly?
There may be other ways to precalculate the date differences for some or all dates. For example if you get a date that is the same monty/day/year of a previous request just look it up in a saved cache.
If you stay with Calendar, you might also be able to use ThreadLocal to make it so you don't need to create new Calendar objects each time.
As an aside I wonder if they will really ever get rid of these date methods that so many people still probably use. Has anyone heard any info on that? [ September 22, 2006: Message edited by: steve souza ]
Using a cache probably wouldn't help, since we deal with Dates with a range of 30 years, which would make quite a large cache
Also we'd prefer to avoid using the deprecated methods, just in case one day Sun finally cleanup the ugly Date class.
Just taking the ms difference isn't enough because the input dates may span a DST switch period, ie one day may have 25 hours or one day may have 23 hours. Hence we have to do the contruction and zeroing of the time portion.
The only solution I can find is to change the dates being passed into the method to not have time information in the first place. That should keep me busy until 2028