|
I have been tracking down performance issues in optimizing MiniGUI
peers for AWT. We are doing pretty well with drawing speed, but we found that Container was very very slow handling the paint method This we tracked down to the MiniGUI peer code, specifically, that it was creating a lot of new instances of various objects in Graphics.create. The performance impact of the object creation was very very high - much higher than you would expect in terms of processor speed proportions. That, and some searches for benchmark results on Kaffe GC lead me to suspect that memory allocation is a performance bottleneck in Kaffe. I was wondering if anyone had similar experiences? So, while we optimize paint performance using the fact that Graphics.create and Graphics.dispose can be used to manage a cache of Graphics instances, and to initialize those instances instead of using "new" (often gratuitously, as it turned out, for things like Color), we think the performance of Kaffe GC might be a general drag on performance. We tried using Boehm GC, but encountered an issue which is now bug #113. Any experiences/pointers getting Boehm GC up on ARM Linux would also be very useful. ZM --
| ||||||||||||
_______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
