At 06:59 PM 12/23/2004, Curt Arnold wrote:
Also, the slot stuff also seemed to up the complexity. I was trying to make it simpler at some trival cost (an extra dateformat per second or so) and still avoid the migrating millisecond field problem, I thought that I had adequately addressed that weakness.
There is no new slot stuff. 'slotBegin' is another name for 'previousTime'. There are no logical changes just string search and replace.
From what I can judge, the biggest difference between version 1.1 and version 1.7 of o.a.l.pattern.CachedDateFormat, can be traced back to the following lines:
Version 1.1:
115 : if (now < previousTime + 1000L && now >= previousTime) {
116 : if (millisecondStart >= 0) {
117 : cache.delete(millisecondStart, millisecondStart + 3);
118 : int millis = (int) (now - previousTime);
119 : int cacheLength = cache.length();
120 : //
121 : // append milliseconds to the end of the cache
122 : numberFormat.format(millis, cache, fieldPosition);
123 : int milliLength = cache.length() - cacheLength;
124 : //
125 : // if it didn't belong at the end, then move it
126 : if (cacheLength != millisecondStart) {
127 : String milli = cache.substring(cacheLength);
128 : cache.setLength(cacheLength);
129 : cache.insert(millisecondStart, milli);
130 : }
131 : for (int i = milliLength; i < 3; i++) {
132 : cache.insert(millisecondStart, "0");
133 : }
134 : }
135 : sbuf.append(cache); 135 : }
As you can see, version 1.1 invokes the cache.insert(). method in the case where (cacheLength != millisecondStart), that is when the millisecond field was not at the end. However, for the most common cases, that is for %d, %d{ISO861}, %d{ABSOLUTE}, %d{DATE_AND_TIME_DATE_FORMAT}, line 129 will not be called. On the other hand, for values of the millisecond field smaller than 100, line 132 will be called at least once.
I am also puzzled by the fact that lines 117 and 131 hard code and assume that the length of the millisecond field will be 3. So how can the patterns containing only 1 or 2 'S' formatted correctly? What am I overlooking?
Version 1.7
165 : if ((now < (slotBegin + 1000L)) && (now >= slotBegin)) {
166 : //System.out.println("Using cached val:"+date);
167 :
168 : // caching is safe only for milliDigits == 3, if milliDigits == 0
169 : // we don't have to bother with milliseonds at all.
170 : if (millisecondStart >= 0 && milliDigits == JVM_MAX_MILLI_DIGITS) {
171 : int millis = (int) (now - slotBegin);
172 : int cacheLength = cache.length();
173 :
174 : milliBuf.setLength(0);
175 : numberFormat.format(millis, milliBuf, fieldPosition);
176 : for(int j = 0; j < JVM_MAX_MILLI_DIGITS; j++) {
177 : cache.setCharAt(millisecondStart+j, milliBuf.charAt(j));
178 : }
179 : }
180 : }
Version never invokes StringBuffer.insert() method. However, it assumes that the millisecond field will always have 3 digits (zero padded when necessary).
In the case the current time is in a different second (1000 millisecond) slot, version 1.1 incurs the overhead of calling formatter.format twice, whereas 1.7 incurs it only once. However, as the slot is 1 second wide, that overhead is paid at most once every second.
At the beginning, I thought that 'SS' meant 10 millisecond precision and 'S' meant 100 milisecond precision. If that were the case, my changes to findMillisecondStart() would have made sense. However, as it stands, 'S' and 'SS' relate to padding with zero, not precision.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
