all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tim Connors <tim.w.connors@gmail.com>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: Re: Memory again
Date: Thu, 15 Dec 2011 14:52:23 +1100 (EST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1112151443390.3735@dirac.rather.puzzling.org> (raw)
In-Reply-To: <jwvliqpebak.fsf-monnier+emacs@gnu.org>

On Tue, 6 Dec 2011, Stefan Monnier wrote:

> > I'm writing this message on that very same emacs process. Right now it
> > has 60 buffers, all of them with a size below 50KB and most below
> > 10KB. As reported by `htop', the process is using 533MB of RES memory
> > and 630MB of VIRT memory.
>
> Nothing of what you say sounds worrisome: apparently you now have around
> half a GB of memory allocated for use by Lisp data.  Most likely the
> majority of it is considered by Emacs as "free for reuse", but it's not
> returned to the OS because that is only done in "big chunks" (typically
> 10KB or so) and none of the big chunks are 100% free (they all contain
> at least one non-free object).
> Some of that memory may also belong to malloc rather than to Emacs:
> Emacs did pass it to `free', but the malloc library decided that it's
> not worth returning those elements to the OS.
> Of course, it may also be that we have an actual leak (i.e. some of that
> memory was neither returned to malloc, nor is it still managed by
> Emacs).  But as long as you don't have evidence of a leak, I'd suggest
> you move on, because there's really not much we can do about the above
> problem (short of rewriting the whole memory management to make it
> compacting).

I recently switched over to Emacs, from XEmacs, porting my .config files
over as necessary.  I am used to being able to run XEmacs for months on
end, with XEmacs's gnuclient, and having hundreds of buffers and dozens of
frames open.  The XEmacs process would sometimes take 100M or so resident,
and if I opened a big file and tried to fontify it, then naturally usage
would increase.  Some of this would be returned to the OS, some of it
wouldn't, when I closed buffers.  I lived with that because I didn't tend
to stupidly open big files and fontify them too often.

But right now, having had emacs up for a few days, and only opening 10
small files with the aid of emacsclient, emacs's RSS is 130M.  It had
climbed up to 400M before I most recently killed it.

What's the differences between emacs's and xemacs's allocators?


By the way, the dismissal of this being a real problem because emacs can
always reuse the fragmented memory either

1) ignores the fact that computers are general purpose and can run other
programs simultaneously (some of them being rather high quality bloatware
like mozilla), or

2) takes the view that emacs is an entire operating system, and there's no
need to run anything else, a little too seriously

-- 
Tim Connors



  parent reply	other threads:[~2011-12-15  3:52 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-26 13:26 Memory again Carsten Mattner
2011-11-26 13:28 ` Carsten Mattner
2011-11-26 14:35 ` Dmitry Antipov
2011-11-26 14:48   ` Eli Zaretskii
2011-11-26 17:37     ` Dmitry Antipov
2011-11-26 20:19       ` Eli Zaretskii
2011-11-26 14:58   ` Carsten Mattner
2011-11-26 16:23     ` Eli Zaretskii
2011-11-26 19:02       ` Carsten Mattner
2011-11-26 20:31         ` Eli Zaretskii
2011-11-26 21:00           ` Eli Zaretskii
2011-11-27 10:29           ` Carsten Mattner
2011-11-27 10:43             ` Andreas Schwab
2011-11-27 13:53               ` Carsten Mattner
2011-11-27 13:11             ` Eli Zaretskii
2011-11-27 13:53               ` Carsten Mattner
2011-11-27 16:44                 ` Eli Zaretskii
2011-11-27 17:37                   ` Carsten Mattner
2011-11-27 17:59                   ` Carsten Mattner
2011-12-06  4:02       ` Óscar Fuentes
2011-12-06  5:08         ` Eli Zaretskii
2011-12-06  9:35           ` Carsten Mattner
2011-12-06 10:24             ` Dmitry Antipov
2011-12-06 13:07               ` Eli Zaretskii
2011-12-06 13:29               ` Stefan Monnier
2011-12-06 17:20                 ` Eli Zaretskii
2011-12-06 20:25                   ` Stefan Monnier
2011-12-07  7:52                     ` Eli Zaretskii
2011-12-07  8:15                       ` Dmitry Antipov
2011-12-07 13:06                         ` Eli Zaretskii
2011-12-07 14:01                           ` Stefan Monnier
2011-12-08 17:30                             ` Carsten Mattner
2011-12-09  3:39                               ` Dmitry Antipov
2011-12-09 13:52                                 ` Carsten Mattner
2011-12-06 13:12             ` Eli Zaretskii
2011-12-06 16:28           ` Óscar Fuentes
2011-12-06 19:53             ` Stefan Monnier
2011-12-11 17:49               ` Nix
2011-12-15  3:52               ` Tim Connors [this message]
2011-12-15  4:09                 ` Eli Zaretskii
2011-12-15  4:38                   ` Tim Connors
2011-12-15  5:52                     ` Eli Zaretskii
2011-12-15  4:50                   ` Óscar Fuentes
2011-12-15  6:04                     ` Eli Zaretskii
2011-12-16 21:55                 ` Stefan Monnier
2011-12-17 17:40                   ` Nix
2011-12-18 15:13                   ` Dmitry Antipov
2011-12-19  1:34                     ` Stefan Monnier
2011-12-19  8:28                       ` Dmitry Antipov
2011-12-19 11:26                         ` Stefan Monnier
2012-01-23 16:49                           ` Nix
2012-01-25 16:19                             ` Ted Zlatanov
2011-11-26 17:54     ` Dmitry Antipov
2011-11-26 18:47       ` martin rudalics
2011-11-26 19:09       ` Carsten Mattner
2011-11-28  4:27     ` Stefan Monnier
2011-11-28  9:24       ` Carsten Mattner
2011-11-28 15:31         ` Davis Herring
2011-11-28 21:33           ` Carsten Mattner
  -- strict thread matches above, loose matches on Subject: below --
2011-12-19 19:51 emacs user
2011-12-20  5:32 ` Dmitry Antipov
2012-01-06 14:28 ` Chong Yidong
2012-01-06 15:53   ` emacs user
2011-12-20  6:34 emacs user
2011-12-20  7:43 ` Eli Zaretskii
2011-12-20 12:05   ` emacs user
2011-12-20 13:04     ` Eli Zaretskii
2011-12-20 22:07       ` Jan Djärv
2011-12-21  8:07       ` Jan Djärv
2011-12-21 10:39         ` Carsten Mattner
2011-12-21 17:55         ` emacs user
2011-12-22 14:08           ` Jan Djärv
2011-12-22 14:58             ` emacs user
2011-12-22 18:54               ` emacs user
2011-12-22 19:15                 ` Jan Djärv
2011-12-23  4:41                   ` YAMAMOTO Mitsuharu
2012-01-17 10:04                     ` emacs user
2012-01-17 10:58                       ` YAMAMOTO Mitsuharu
2012-01-17 13:14                         ` emacs user
2012-01-18  1:30                           ` YAMAMOTO Mitsuharu
2011-12-22 23:09                 ` Carsten Mattner
2011-12-23  0:39               ` Stefan Monnier
2011-12-23 10:44                 ` emacs user
2012-01-05  6:13                   ` emacs user
2012-01-05 22:37                     ` Jan Djärv
2012-01-06  9:58                       ` emacs user
2012-01-06 11:10                         ` Carsten Mattner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1112151443390.3735@dirac.rather.puzzling.org \
    --to=tim.w.connors@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.