From: David Kastrup <dak@gnu.org>
Cc: Lute Kamstra <Lute.Kamstra.lists@xs4all.nl>,
reiner.steib@gmx.de, ding@gnus.org, emacs-devel@gnu.org,
storm@cua.dk, snogglethorpe@gmail.com, miles@gnu.org
Subject: Re: require inside functions.
Date: Fri, 08 Apr 2005 10:16:47 +0200 [thread overview]
Message-ID: <x5br8pn0nk.fsf@lola.goethe.zz> (raw)
In-Reply-To: <E1DJk4c-0007Kv-Uq@fencepost.gnu.org> (Richard Stallman's message of "Thu, 07 Apr 2005 23:22:22 -0400")
Richard Stallman <rms@gnu.org> writes:
> (require 'ft) only loads a file if 'ft is not in features. However,
> it unconditionally adds '(require . ft) to current-load-list. If you
> call a function with require a million times, this eats up 16 MB of
> memory.
>
> This was done deliberately. The idea is that it's useful
> to record that file foo depends on file bar, even if bar
> was already loaded before foo.
>
> However, it isn't useful to record (require . bar) an additional
> time in current-load-list when it's already there. So I think the
> right fix is to check with Fmember and not add it a second time.
Probably a performance issue? Maybe the check for it already being
present should be done using a hashtable, say current-load-hashtable?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2005-04-08 8:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1DGYNu-00038g-00@quimby.gnus.org>
[not found] ` <yotly8c5jpi2.fsf@jpl.org>
2005-03-31 11:27 ` Changes in calendar/time-date.el (was: CVS update of gnus/lisp (4 files)) Reiner Steib
2005-03-31 12:20 ` Miles Bader
2005-03-31 12:58 ` Changes in calendar/time-date.el Lute Kamstra
2005-03-31 22:52 ` Miles Bader
2005-04-01 4:10 ` Richard Stallman
2005-04-04 10:25 ` Reiner Steib
2005-04-04 10:57 ` Lute Kamstra
2005-04-04 12:09 ` Reiner Steib
2005-04-04 12:52 ` Lute Kamstra
2005-04-04 17:20 ` Reiner Steib
2005-04-04 19:50 ` Stefan Monnier
2005-04-05 7:14 ` Kim F. Storm
2005-04-05 9:33 ` Miles Bader
2005-04-05 10:06 ` Kim F. Storm
2005-04-07 12:47 ` require inside functions. (was: Changes in calendar/time-date.el) Lute Kamstra
2005-04-07 21:45 ` Kim F. Storm
2005-04-08 0:12 ` require inside functions Miles Bader
2005-04-08 0:45 ` Stefan Monnier
2005-04-08 2:09 ` Miles Bader
2005-04-08 0:21 ` Stefan Monnier
2005-04-08 3:22 ` require inside functions. (was: Changes in calendar/time-date.el) Richard Stallman
2005-04-08 8:12 ` Kim F. Storm
2005-04-09 3:38 ` require inside functions. (was: Changes in Richard Stallman
2005-04-09 9:30 ` require inside functions Lute Kamstra
2005-04-10 1:55 ` Richard Stallman
2005-04-13 9:11 ` Lute Kamstra
2005-04-15 2:44 ` Richard Stallman
2005-04-15 9:23 ` Lute Kamstra
2005-04-08 8:16 ` David Kastrup [this message]
2005-04-05 13:54 ` Changes in calendar/time-date.el Lute Kamstra
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=x5br8pn0nk.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=Lute.Kamstra.lists@xs4all.nl \
--cc=ding@gnus.org \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
--cc=reiner.steib@gmx.de \
--cc=snogglethorpe@gmail.com \
--cc=storm@cua.dk \
/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.