Gnus development mailing list
 help / color / mirror / Atom feed
From: gsstark@mit.edu (Gregory S. Stark)
Cc: ding@gnus.org
Subject: Regular expression performance in emacs, number of cached regexps
Date: 17 May 1998 13:49:54 -0400	[thread overview]
Message-ID: <ycqyaw023el.fsf@portD41.Generation.NET> (raw)


In profiling an elisp program I was working on I found that an inordinate
quantity of string memory was being allocated in a function I thought I had
optimized extensively. Using the source, I eventually found that the memory
was allocated by the regular expression searching functions to cache a small
constant number of compiled regular expressions.

Unfortunately in my code, which was fairly short and simple, the behaviour was
pathological. If I recall correctly, Emacs cached the five most recently used
compiled regular expressions, and I was looping through about six or seven. So
Emacs was repeatedly recompiling the same six or seven regular expressions and
allocating memory only to be thrown away as garbage shortly later, causing
excessive regular expression compilations and garbage collections.

I've since optimized my package to use less than five regular expressions, but
my concern is that several other large packages including W3 and Gnus use
re-search-forward and looking-at liberally in code that is otherwise quite
carefully optimized (more or less). Reducing the number of regular expressions
these packages use in loops is likely to be quite hard. I suspect increasing
the compile-time configuration constant governing the size of this cache will
be a big speed and memory boost for these packages.

greg

In case people are curious, here is the code I use to profile memory usage in
my packages. I've suggested something like this be integrated in elp.el, which
I don't think would really be all that hard, but I don't think elp.el is under
active development, which is a shame, it's a great tool.

(defadvice the-function-to-profile (around profile-memory)
  (let (before after delta)
    (setq before (memory-use-counts))
    ad-do-it
    (setq after (memory-use-counts))
    (while before
    (push (- (pop after) (pop before)) delta))
    (apply 'message
           "MEMORY USE cons:%d fl:%d vec:%d sym:%d str:%d misc:%d int:%d"
           (nreverse delta))))



             reply	other threads:[~1998-05-17 17:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-17 17:49 Gregory S. Stark [this message]
1998-05-17 19:20 ` Kai Grossjohann
     [not found] ` <vafhg2o1z7k.fsf@ramses..cs.uni-dortmund.de>
1998-05-17 19:33   ` Hrvoje Niksic
1998-05-18  5:29 ` Richard Stallman
1998-05-18 15:49   ` William M. Perry
1998-05-19  4:45     ` Richard Stallman
1998-05-19 13:52       ` William M. Perry
1998-05-20  1:38         ` Richard Stallman
1998-05-20  6:43       ` Dale Hagglund
1998-05-20 11:47         ` William M. Perry
1998-05-21  7:13         ` Richard Stallman
1998-05-19  7:55   ` Jan Vroonhof

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=ycqyaw023el.fsf@portD41.Generation.NET \
    --to=gsstark@mit.edu \
    --cc=ding@gnus.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).