logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: cvs commit: logging-log4j/tests/src/java/org/apache/log4j/pattern CachedDateFormatTest.java
Date Thu, 23 Dec 2004 21:31:14 GMT

BTW, regardless of the constructor change of CachedDateFormat, lines
165 to 180 of version 1.8 are preferable to lines 115 to 135 in
version 1.8. You could revert the constructor to
CachedDateFormat(DateFormat) and still keep lines 165 to 180.

You could also take out

     String cleanedPattern = CacheUtil.removeLiterals(pattern);
     milliDigits = CacheUtil.computeSuccessiveS(cleanedPattern);

     if(!CacheUtil.isPatternSafeForCaching(cleanedPattern)) {
       millisecondStart = BAD_PATTERN;
       return;
     }

and place it in DatePatternConverter.

At 09:07 PM 12/23/2004, Ceki Gülcü wrote:
>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: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org

-- 
Ceki Gülcü

   The complete log4j manual: http://qos.ch/log4j/



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message