Curt,
You are several steps ahead of me. I had seen but had not paid attention to:
if (now < previousTime + 1000L && now >= previousTime) {
...
else {
....
//
// if the length changed then
// recalculate the millisecond position
if (cache.length() != prevLength) {
....
// detect the start of the millisecond field
millisecondStart = findMillisecondStart(previousTime,
tempBuffer.toString(),
formatter);
}The above lines nicely take care of the case where the position of the millisecond field in the formatted output varies over time. The above is both simple and efficient - brilliant stuff.
At 12:01 AM 12/21/2004, Curt Arnold wrote:
For those tuning in late: The basic idea of the cached date format is that if the time is within the same integral second as a previous request, then only the milliseconds field needs to be rewritten. To find the milliseconds field, on the first request (or any request where the total length of the formatted field has changed), two times only differing in the number of milliseconds are output and the results are analyzed. If the milliseconds format is unrecognized, then the CachedDateFormat will simply delegate to the underlying DateFormat.
I apologize for forcing you to explain this allover again and wasting your time.
CachedDateFormat would not be able to detect the milliseconds field on RelativeTimeDateFormat unless the starting time was an integral second and would not be able to detect millisecond fields if non-arabic digits were set. In either of these cases, you would have an extra call per format evaluation. I believe the original patch avoided caching RelativeTimeDateFormat.
Making DatePatternConverter aware of CachedDateFormat would avoid caching RelativeTimeDateFormat.
The worse-case scenario is if you could construct a date-time format where the location of the millisecond field changed, but the total length of the field did not. I don't think that you could create one with SimpleDateFormat, however you could obviously write a custom DateFormat that did.
It could only happen if at some point in time, some field or field we shorted and one or more fields were shortened by the same amount. If a simple algorithm could be devised to detect such cases beforehand, then CachedDateFormat is a winner.
There is an observable difference when running the performance tests to a null appender with CachedDateFormat. However, it may not be significant in more realistic deployments. It is a significant improvement over the flawed (and currently unused) caching code in the original DateFormats. However, the original motivation for the caching may no longer be relevant and so a new CachedDateFormat may not have a performance benefit that justifies the added complexity.
Mostly agreed. However, I still wonder whether with a little extra work CachedDateFormat could not be polished to become a pearl.
The second pass used localized values of both 0 and 9 to identify the millisecond field. If the default locale changed, CachedDateFormat would not switch locales until the next integral second. There may be other issues that come to pass with any locale rework, so maybe the best approach is to leave CachedDateFormat out for now. It will be available in Bugzilla in case someone ever wants to add it later.
I'll give it a shot if you don't mind.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
