From: "Richard M. Stallman" <rms@gnu.org>
Cc: cyd@stupidchicken.com, yamaoka@jpl.org, emacs-devel@gnu.org
Subject: Re: Slow Info startup
Date: Fri, 02 Dec 2005 13:21:47 -0500 [thread overview]
Message-ID: <E1EiFXX-0003si-R4@fencepost.gnu.org> (raw)
In-Reply-To: <878xv4h4l1.fsf@jurta.org> (message from Juri Linkov on Thu, 01 Dec 2005 23:47:54 +0200)
The old code uses `file-name-nondirectory' to remove directory part
from absolute file names in the history before comparing them to the
name extracted from a menu item or cross-reference.
In general, that could make a mistake.
The new code uses
`Info-find-file' to find the absolute file name of a menu item
or cross-reference before comparing it to absolute file names in
the history.
In general, that is more correct.
`Info-find-file' is a quadratically slow function that
iterates over `Info-directory-list' and `Info-suffix-list' to find the
absolute Info file name.
Indeed, this is slow. Would it solve the problem to maintain a cache
that records arguments that were given to Info-find-file together with
the results that were obtained?
Or is even one call for each file too slow?
Another idea: get the directory lists of the directories in
Info-directory-list. Then Info-find-file can do its work without
actually trying to open the files, by scanning those lists instead.
Maybe that would be both fast enough and 100% correct.
Yidong wrote:
Actually, we only need to use file-name-nondirectory for Info node
names specifying other info files. This way, links within info files
will always be highlighted correctly, even for info session started
with Info-on-current-buffer (external links will still have the flaw
discussed previously).
Both methods could be speeded up this way. If you use this technique
to optimize the Info-find-file method, does that make it fast enough?
prev parent reply other threads:[~2005-12-02 18:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-30 1:40 Slow Info startup Katsumi Yamaoka
2005-11-30 2:38 ` Chong Yidong
2005-11-30 2:41 ` Chong Yidong
2005-11-30 2:48 ` Juri Linkov
2005-11-30 3:19 ` Katsumi Yamaoka
2005-12-01 6:05 ` Richard M. Stallman
2005-12-01 21:47 ` Juri Linkov
2005-12-01 22:46 ` Chong Yidong
2005-12-02 0:03 ` Juri Linkov
2005-12-02 18:21 ` Richard M. Stallman [this message]
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=E1EiFXX-0003si-R4@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=yamaoka@jpl.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.
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.