Berin, >> <sigh> this stuff is so demotivating :-/. > >I feel your pain.
Glad to here... >>>Pooling objects will cause them to live longer than necessary. The >>>garbage collection methods will be much more efficient if you let it >>>do the memory management. We strongly advise taking out object pools. >>> >>>[ Editorial note: Component pooling and connection pooling have real >>> measured performance gains. These are due to the fact that they are >>> expensive to create. The comment is more for simple objects that are >>> pooled. ] >>> >> >> Ok but we pool our objects to increase our generating performance. I think >> that's a good deal, or? > >The editorial notes are mine. We have measured performance gains due to the >fact that our Components are heavy to instantiate. The Pooled object argument >is only valid for small objects like String or Object where the initialization >is quick, and the teardown is quick. Yep. >>>Don't call System.gc(), HotSpot will make the determination of when its >>>appropriate and will generally do a much better job. If you are having >>>problems with the pause times for garbage collection or it taking too long, >>>then see the pause time question above. >>> >>>[ Editorial note: There is an option to disable explicit garbage collecting >>> calls to test this statement. (-XX:-DisableExplicitGC) ] > > >Did you test the system with this option enabled to see if we get any performance >increase? Nope, but I have strong feeling it was more the opposite. >>>Warming up loops for HotSpot is not necessary. HotSpot now contains On >>>Stack Replacement technology which will compile a running (interpreted) >>>method and replace it while it is still running in a loop. No need to >>>waste your application's time warming up seemingly infinite (or very long >>>running) loops in order to get better application performance. >>> >>>[ Editorial note: This does not apply to benchmarking. Do warm up the >>> VM by running your benchmark for a period of time before collecting >>> results. ] >>> >> >> Hmm more stuff to think about! Is this only Hotspot. How when people use >> the classic JVM? I have long discussion in the jakarta-commons group. Some >> people say, that the JVM GC is doing a good job and it would be better to >> let him work. > >With JDK versions 1.3 and later, they are all HotSpot VMs. Even IBM's JVM >exibits much of the same functionality. I have a feeling that the number >of people using classic VMs will evaporate to nothing. This is especially >true when people want to squeeze performance out of their apps--and the >newer VMs do provide more flexibility in making those optimizations. Ok. >> In the meantime I have the same opinion. You can't really control the JVM. >> I try this now over a very long period and somehow I don't get to a really >> success. Maybe it would be better throw out this StoreJanitor stuff and Co. >> and only do the LRU and MRU stuff. Or we leave the StoreJanitor, but don't >> call the GC anymore! > >Let's take out the explicit calls to GC--but keep actively maintaining cache >coherency. It would be interesting to see how it compares. I commented it out. Let's see how it works! >> It's no problem for me. I'm not married with that stuff and don't wanna hinder >> the success of Cocoon. > >Glad to hear it. Otherwise it's the dead of each SW project. ~Gerhard "EARTH FIRST! We'll strip-mine the other planets later." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
