after we did some enhancements to the buffer management (audio calls) I was
interested to see the effects of our enhancements. I used some available
profiler (mainly those available in Sun Java SDK 6) to watch the runtime
behaviour of SC. Here are some interesting results:
OpenSuse Linux 11.2, 64-bit dual core AMD processor 4200+, 8GB RAM,
Sun JDK 6, 64bit
After starting SC I waited a few seconds to see the idle time behaviour:
SC uses < 2% CPU and burns about ~1MB (MegaByte) heap storage per second,
depending on the memory configuration this requires a full garbage collector
(GC) run every 2 to 3 minutes
The behaviour during an audio call (not secured):
SC uses about 15-17% CPU and burns a whopping 4MB heap storage per second
which requires a full GC run every 30 seconds (depends on memory config).
Using some enhanced techniques (a specific profiler that monitors object
allocations) I found a big memory hog: the sound level display. The graphic
interface that shows the sound level is resonsible for this enormous
memnory consumption (plus and overwhelming number of object allocations).
The behaviour during an audio call (not secured) without sound level display:
SC uses about 7-8% CPU, heap memory consumption is similar to the idle
behaviour (~1MB per second).
A good news: the GC regularly can reclaim all used heap memory, thus I
didn't see a major memory leak in SC (yet ) .
Some questions remain: what causes a memory consumption of about 1MB per
second in idle mode? Shall we implement a method to enable on/off toggle
of the sound level display (would make sense for low CPU/small memory