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

Re: Bug#252481: apt-utils.el: swelling emacs memory use



>>>>> "M" == Matt Hodges <matt@stchem.bham.ac.uk> writes:

>>>>> Dan Jacobson writes:
>> Just for fun, I started two emacs -q's, and then ran top(1).
>> In one I typed M-x apt-utils-show-package RET
>> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>> 1655 jidanni   11   0 10692  10m 4068 S  0.0  4.2   0:10.12 emacs
>> 1653 jidanni    9   0  7832 7832 4036 S  0.0  3.1   0:00.85 emacs

>> But, if I were to do a simple command line $ apt-cache show
>> some_package no "permanent memory swelling" or whatever "price need
>> be paid". So, though no computer expert, I suspect something
>> inefficient is going on here. Of course I only do a couple of
>> apt-cache show's a day, so I may not be the typical power user.

M> Well, if inefficient equals caching data, then yes, I suppose so.
M> There is a hashtable that holds the package names and their types
M> (normal or virtual), and two lists that are used by completing-read in
M> apt-utils-show-package. (For the next release of GNU Emacs,
M> completing-read will be able to use the hashtable directly, so the
M> other lists become redundant.)

M> There are a few approaches that could be used to reduce memory usage:

M> (1) Calculate the two lists mentioned above when needed, but don't
M>     keep them in memory.

M> (2) Optionally, don't use these list at all, and type in package
M>     names without completion.

M> (3) Have a hook that can be run in apt-utils-kill-buffer (bound to Q
M>     by default) that could run a cleanup function to nuke the
M>     hashtable and lists. You have to bear in mind that even after such
M>     a cleanup, the memory may not be freed to the OS, and may only be
M>     usable by Emacs.

M> I don't think (1) is a good idea. I mostly favour (3) as a compromise
M> between reducing memory overhead for occasional users, and increased
M> complexity of the code. What do you think about an
M> apt-utils-kill-buffer-hook, documented with this purpose in mind?

>> Maybe add some commentary in the docstrings as to how many times
>> one would need to use it a day for it to be worth keeping it all in
>> emacs memory or whatever.

M> Personally, using Emacs for so many other things, I never noticed the
M> memory overhead, but admit that for others it might be significant.

Well, simple users wouldn't remember to hit Q when finished to clean
up or whatever.  I was hoping for something like M-x man: highly
sensitive to what the cursor is upon for giving defaults when asking
things in the minibuffer.  And mainly "no long green meter pegging in
the little square at the bottom of my screen" upon starting.

Also, lets say the names you were keeping track of were just names of
files in some large directory. It seems how emacs treats those isn't
as "filling" as they say in beer ads, however I'm just going by feel,
never took measurements.

Anyway, all I know is for one or two apt-cache searches or whatever a
day, the command line version is for me--no big investment for one
shot use.

Cc'ing to the list just to spark up things. However as no computer pro
perhaps I'm off my rocker and apt-utils-show-package is just right for
power users.



Reply to: