[sip-comm-dev] SC and some runtime statistics and behaviour


#1

All,

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:

System:
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 :wink: ) .

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
devices)?

Regards,
Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Werner,

Thank you very much for the analysis!

Some questions remain: what causes a memory consumption of about 1MB per
second in idle mode?

Does idle mode mean that SIP Communicator is running with no accounts?
If there are any accounts, I guess we have to also keep in mind that
there is likely networking activity in the background such as keep
alives, for example.

Shall we implement a method to enable on/off toggle
of the sound level display (would make sense for low CPU/small memory
devices)?

While audio level functionality is known to be intensive in terms of
memory and display updates and we could certainly have a configuration
property to disable it, don't you think we should first try to
optimize it? I realize we may not be able to do much after we call
Component#repaint().

Best regards,
Lubo

···

On Sat, May 22, 2010 at 10:21 AM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

One quick question.

На 22.05.10 09:21, Werner Dittmann написа:

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).

When you disabled sound levels did you only turn off their display, or
did you also turn off the measurements? Note that, preventing the UI
listeners to register for audio levels would also prevent the whole
measurement and event notification.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey all!

На 22.05.10 11:56, Lubomir Marinov написа:

Hi Werner,

Thank you very much for the analysis!

+1, thanks Werner!

While audio level functionality is known to be intensive in terms of
memory and display updates and we could certainly have a configuration
property to disable it, don't you think we should first try to
optimize it? I realize we may not be able to do much after we call
Component#repaint().

+1 to that too. I think it shouldn't be hard to optimize this part. Of
course if this doesn't help then we could definitely think of a way that
would allow users to easily disable them.

Anyone wants to create an issue so that we don't forget about it?

Cheers,
Emil

···

On Sat, May 22, 2010 at 10:21 AM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Lobo,

Hi Werner,

Thank you very much for the analysis!

Some questions remain: what causes a memory consumption of about 1MB per
second in idle mode?

Does idle mode mean that SIP Communicator is running with no accounts?
If there are any accounts, I guess we have to also keep in mind that
there is likely networking activity in the background such as keep
alives, for example.

Yes, a Jabber account and the SIP account, not more. Yet ~1MB per second
is quite a mouthful :slight_smile: .

Shall we implement a method to enable on/off toggle
of the sound level display (would make sense for low CPU/small memory
devices)?

While audio level functionality is known to be intensive in terms of
memory and display updates and we could certainly have a configuration
property to disable it, don't you think we should first try to
optimize it? I realize we may not be able to do much after we call
Component#repaint().

Maybe, I'm not a specialist for graphic stuff at all and I have no idea
how to optimize this.

Regards,
Werner

···

Am 22.05.2010 11:56, schrieb Lubomir Marinov:

On Sat, May 22, 2010 at 10:21 AM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Best regards,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Emil,

I just commented one line in AudioLevelEffect:

        //now copy the output to the level dispatcher.
//*** eventDispatcher.addData(outputBuffer);

thus only disabling the delivery of the events to the dispatcher and
thus disabling graphics update.

Regards,
Werner

···

Am 22.05.2010 15:01, schrieb Emil Ivov:

One quick question.

На 22.05.10 09:21, Werner Dittmann написа:

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).

When you disabled sound levels did you only turn off their display, or
did you also turn off the measurements? Note that, preventing the UI
listeners to register for audio levels would also prevent the whole
measurement and event notification.

Emil


#7

just as an add-on info:

according to the traces I did the main "memory eater" :slight_smile: is the graphics
subsystem, a large number of abject allocations. IMHO the event delivery and
the computation does not use that much memory (without having looked into that
in depth)

Regards,
Werner

···

Am 22.05.2010 15:01, schrieb Emil Ivov:

One quick question.

На 22.05.10 09:21, Werner Dittmann написа:

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).

When you disabled sound levels did you only turn off their display, or
did you also turn off the measurements? Note that, preventing the UI
listeners to register for audio levels would also prevent the whole
measurement and event notification.

Emil