Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#510 closed Nitpick (invalid)

Quite enormous memory usage

Reported by: murks@… Owned by: David Robillard
Priority: minor Component: Patchage
Keywords: Cc:

Description

Hi. I do prefer patchage for managing connections over everything else, but it appears to be quite a memory hog. My system only has 1GB, so the amount it uses seems significant. Note that I don't really know how to interpret memory values correctly, so here's what top says: VIRT/RES/SHR 332m 187m 150m 18.8 %

It just seems a lot. Not sure it increases with the number of ports or connections. The values above are with almost nothing running...

Change History (17)

comment:1 Changed 11 years ago by David Robillard

SHR is shared memory, and (very roughly) can be subtracted from RES. So patchage is using around 37m here.

I'm guessing all Jack applications show similar figures?

comment:2 in reply to:  1 Changed 11 years ago by anonymous

Replying to dave:

SHR is shared memory, and (very roughly) can be subtracted from RES. So patchage is using around 37m here.

I'm guessing all Jack applications show similar figures?

If you substract SHR from RES then it comes close, otherwise it looks like a huge difference.

name VIRT RES SHR

yoshimi 120m 66m 18m phasex 191m 102m 28m patchage 333m 188m 158m ardour 874m 289m 157m qjackctl 149m 51m 30m jackd 39512 23m 5652

So it's another case of wrong interpretation of memory figures?

comment:3 Changed 11 years ago by David Robillard

Hm, interesting.

Partially, but clearly Patchage is using more memory in some respect (even if potentially shared) than other things which are also using Jack. I can't think of any reason this should be the case (i.e. I agree with your intuition that Patchage seems to be using much more than it should need here)

I will do some profiling and try to figure out where.

Which version are you using, and with which Jack driver (libjack or dbus). Or, if you don't know the latter, where'd the package come from?

comment:4 Changed 11 years ago by murks@…

The system is x86_64.
patchage 0.4.4
tschack-git 20100603 (libjack)

Thanks for looking into this. Regards, Philipp

comment:5 Changed 11 years ago by Maxux

On my Gentoo, using Patchage 0.4.4 (on x86 system, same problem on x86_64 on my laptop), Patchage use 125 Mo of memory (VmSize?). I like this software, very easy and intuitive but I can't keep it open with this memory usage. If you find a issue to fix it, that will be great.

comment:6 Changed 11 years ago by David Robillard

Resolution: fixed
Status: newclosed

r2689 and r2690 should have reduced memory consumption a bit.

I don't see any unreasonable memory consumption from patchage (RES = 30M with a moderately sized session).

If you're still getting high values (e.g. RES > 100M), please reopen this bug and provide more information (how many modules, ports, connections are present? Alsa? Libjack? JackDBus?)

comment:7 Changed 10 years ago by Maxux

Resolution: fixed
Status: closedreopened

Hi,

Sorry, I reopen this bug.

System

Linux version 2.6.39-maxux32 (root@fany) (gcc version 4.5.2 (Gentoo 4.5.2 p1.0, pie-0.4.5) ) #2 SMP PREEMPT Sat May 28 21:35:35 CEST 2011

[I] media-sound/patchage
     Installed versions:  0.5.0(03:17:43 30/01/11)(alsa -debug -lash)

[I] media-sound/jack-audio-connection-kit
     Installed versions:  0.120.1(05:52:58 01/05/11)(alsa mmx sse -3dnow -altivec -coreaudio -cpudetection -debug -doc -examples -oss)

[I] media-libs/alsa-lib
     Installed versions:  1.0.24.1(05:31:19 01/05/11)([...] python -alisp -debug -doc -static-libs)

Just when I launch patchage, it use a lot of memory:

htop

  PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command                                                        
23008 geek      20   0  124M  124M 96492 S  3.0  6.1  0:04.90 patchage
(note: 6.1% of 2 Go)

/proc/pid/status

VmPeak:   128044 kB
VmSize:   127464 kB
VmLck:    127460 kB
VmHWM:    127780 kB
VmRSS:    127140 kB
VmData:    12072 kB
VmStk:       136 kB
VmExe:       220 kB
VmLib:     48224 kB
VmPTE:       140 kB
VmSwap:        0 kB

Screenshot

Image(http://www.maxux.net/perso/maxux/patchage-memory.png)?

Here is a repport from friends on IRC:

Debian Sid (x86_64), (jackdmp 1.9.7):
-> RES: 121M
-> VIRT: 341M

Arch (x86_64), patchage 0.5.0, with 6 clients, 34 i/o (jackdmp 1.9.7):
-> RES: 43M
-> VIRT: 287M

When will I have time, I will take a look at the code too. I hope this informations will help you.

Regards, Maxux.

comment:8 Changed 10 years ago by David Robillard

Resolution: invalid
Status: reopenedclosed

Sigh.

VIRT and RES in top do not reflect actual memory consumption of programs.

SHR is shared memory, and is a part of VIRT and RES, e.g. Patchage is using something around 30 MiB of memory in your example.

Unless you are actually running out of memory, you have no reason to be worrying about memory consumption figures you do not understand anyway...

comment:9 Changed 10 years ago by David Robillard

Confirmed with valgrind's massif tool just to be sure. The vast majority of memory for sessions with many ports is pango (text rendering) stuff. I have 160 ports present, Patchage uses 19.38 MiB memory at its peak.

I do wish Pango and/or Gnomecanvas used less memory, but 20 MiB is reasonable enough.

tl;dr: Patchage does not use several hundred megs of RAM.

comment:10 Changed 10 years ago by Maxux

If you're still getting high values (e.g. RES > 100M), please reopen this bug and provide more information (how many modules, ports, connections are present? Alsa? Libjack? JackDBus?)

In answer to this, I reopened the post. Well, please don't sigh.

Unless you are actually running out of memory, you have no reason to be worrying about memory consumption figures you do not understand anyway...

My system is overloaded, I'm out memory.

My custom code to list VmRSS (Resident Set Size) used on my machine says:

[...]
 6176   | fail2ban-server             | 5.520 Mo 
 25258  | irssi                       | 6.168 Mo 
 10945  | irssi                       | 7.137 Mo 
 5956   | hddtemp                     | 8.594 Mo 
 5803   | mysqld                      | 23.551 Mo 
 13251  | chrome                      | 23.918 Mo 
 9499   | darkice                     | 26.102 Mo 
 9397   | meterbridge                 | 28.207 Mo 
 9388   | jackd                       | 30.352 Mo 
 25706  | notification-da             | 30.547 Mo 
 2536   | apache2                     | 30.824 Mo 
 2533   | apache2                     | 30.840 Mo 
 13253  | chrome                      | 34.660 Mo 
 1540   | geany                       | 34.824 Mo 
 3954   | geany                       | 36.812 Mo 
 307    | geany                       | 37.172 Mo 
 28458  | chrome                      | 37.730 Mo 
 10911  | urxvtd                      | 39.211 Mo 
 10943  | sylpheed                    | 43.316 Mo 
 17905  | chrome                      | 46.750 Mo 
 13283  | chrome                      | 52.219 Mo 
 31437  | chrome                      | 52.660 Mo 
 13300  | chrome                      | 55.547 Mo 
 32084  | chrome                      | 59.152 Mo 
 30050  | skype                       | 64.016 Mo 
 13323  | chrome                      | 67.371 Mo 
 28430  | chrome                      | 67.816 Mo 
 6713   | mplayer                     | 70.508 Mo 
 24404  | chrome                      | 72.395 Mo 
 15924  | chrome                      | 74.918 Mo 
 29577  | chrome                      | 78.340 Mo 
 23176  | chrome                      | 84.566 Mo 
 30276  | patchage                    | 124.102 Mo 
 10880  | X                           | 141.020 Mo 
 13237  | chrome                      | 149.398 Mo 
 25397  | rtorrent                    | 163.285 Mo 
--------+-----------------------------+-----------------
 PID    | Name                        | VmRSS

Well, you see, patchage on my list uses a lot of memory. You understand why I'm surprised. If it's because you're using libs like Pango, etc. that I don't use with other app, I understand that you cannot change. But don't says I'm talking about something that I don't understand.

comment:11 Changed 10 years ago by David Robillard

If you think resident set size directly correlates to real memory use per application, then you don't understand it.

comment:12 Changed 10 years ago by David Robillard

(Commenting does not automatically reopen tickets, BTW)

As it happens, due to some changes to jack 0.120.0, I should be able to shave a few megs off the memory usage, but that's about it. Believe me, when a clear alternative to the piece of trash that is gnomecanvas presents itself, and I have the time, I will switch to it eagerly.

comment:13 Changed 10 years ago by Maxux

If you think resident set size directly correlates to real memory use per application, then you don't understand it.

I don't think that. I compare with others apps lauched.

(Commenting does not automatically reopen tickets, BTW)

I know. BTW, (comment 8), you closed it. I won't reopen it.

Believe me, when a clear alternative to the piece of trash that is gnomecanvas presents itself, and I have the time, I will switch to it eagerly.

That's a good news :)

comment:14 Changed 10 years ago by David Robillard

Did some more experimenting; you can verify what I am saying about memory figures by building against Jack+DBus, where RES drops to 26 MiB. The vast majority of that "memory" is libjack shared memory buffers.

comment:15 Changed 10 years ago by David Robillard

That said... I discovered a trick to help (idea seeded by Paul Davis), avoiding Gnome::Canvas::Text entirely and just rendering it 'by hand' and keeping a pixbuf around to draw.

You should see a pretty dramatic improvement with http://dev.drobilla.net/changeset/3350

comment:16 Changed 10 years ago by Maxux

Before (0.5.0)

 6554   | patchage                    | 121.657 Mo

After (svn version)

 7887   | patchage                    | 63.973 Mo

Nice one !

comment:17 Changed 10 years ago by David Robillard

Why thank you :)

Unfortunately the appearance of the text is a bit off now, but I should be able to touch that up.

Oh, gnomecanvas...

Note: See TracTickets for help on using tickets.