DO NOT REPLY [Bug 6858] - Easy & Significant Performance Improvement

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6858>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6858

Easy & Significant Performance Improvement





------- Additional Comments From osvaldo@visionnaire.com.br  2002-05-29 15:30 -------
Just some additional data.

* Allocating big arrays w/o necessity may hurt some GC engines. The allocator
  may have a policy of skipping the young generation for objects bigger than
  some maximum limit, so these objects would be allocated directly in the
  old-generation and totally screw with thee benefits of generational GC;
  the result is that you need full-GC's instead of generational-GCs for
  deleting these buffers, which could explain big and frequent GC pauses.
  Other VMs may segregate objects by size, having many small heaps for different
  ranges of size, so the freespace control is faster as each heap is an array
  and a single bit can track each slot's position; IBM is one JVM that's known
  to have this architecture -- and very large objects will spoil the trick again
  because the segregated heaps exist only for a small number of size ranges.

* A default policy of 512 bytes looks good, this should be good enough for the
  output of most tags.  Some tags produce a lot of output and it would be
  important to set a bigger buffer for making the I/O more efficient, but this
  is less severe than the memory management problem.  For pages we can set the
  buffer size, unfortunately not for tags so this may be a good RFE for the
  JSP spec?  Meanwhile, the lesser evil is using a small buffer.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>