Re: Why does eggcups appear to map shared objects (code) twice?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 28, 2005 at 09:30:21PM -0500, David Cary Hart wrote:
> On Fri, 2005-01-28 at 18:04 -0800, Nifty Hat Mitch wrote:
> > >      1.  I  think  eggcups  is the process for printing. Why it takes up
> > >      more  than  40mb  memory?
> > 
> > In another thread someone noted that eggcups used a lot of memory.
> > Clearly to me it is too big a process to sit idle for most of the month
> > when I print one or two pages a month.  So I looked at it quickly.
> > 
> > When I looked at /proc/<PID-of-eggcups>/maps 
> > I see numerous apparent duplications and some triples
> > that I do not understand.
> 
> Eggcups is not running on my machine - just cupsd and I just printed
> some stuff to a network printer. It's part of desktop-printing which - I
> THINK - is part of gnome. Could it be that by my running KDE I don't
> have this bloat?

Somehow I would like to address the 
Subject....  
    "Why does eggcups appear to map shared objects (code) twice?"

I doubt that eggcups is the only application that might display
this same /proc/*/maps anomaly.

> > Here are examples.
> > 
> >   08048000-0804d000 r-xp 00000000 03:03 344956     /usr/bin/eggcups
> >   0804d000-08050000 rw-p 00005000 03:03 344956     /usr/bin/eggcups
> >   07bba000-07c7f000 r-xp 00000000 03:03 7716904    /usr/X11R6/lib/libX11.so.6.2
> >   07c7f000-07c82000 rw-p 000c5000 03:03 7716904    /usr/X11R6/lib/libX11.so.6.2
> >   0099a000-009bb000 r-xp 00000000 03:03 8306733    /lib/tls/libm-2.3.3.so
> >   009bb000-009bc000 r--p 00020000 03:03 8306733    /lib/tls/libm-2.3.3.so
> >   009bc000-009bd000 rw-p 00021000 03:03 8306733    /lib/tls/libm-2.3.3.so
> > 
> > 
> > Of the 160 mapped chunks the vast majority are apparently duplicated
> > and some are even triples.  The result is a footprint more than 2x
> > what I think is necessary.  I do suspect that much of this is virtual
> > memory magic but I lost my magic memory decoder ring.   Is this 
> > partly why the application "looks" so large>
> > 
> > Are these stack, heap, local variables and such for each library?
> > 


-- 
	T o m  M i t c h e l l 
	spam unwanted email.
	SPAM, good eats, and a trademark of  Hormel Foods.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux