From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 13539@debbugs.gnu.org
Subject: bug#13539: Use fdopendir, fstatat and readlinkat, for efficiency.
Date: Mon, 28 Jan 2013 16:37:48 +0200 [thread overview]
Message-ID: <83obg9idab.fsf@gnu.org> (raw)
In-Reply-To: <51063829.3020500@cs.ucla.edu>
> Date: Mon, 28 Jan 2013 00:34:49 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 13539@debbugs.gnu.org
>
> > Is it really worth our while to spend energy on speeding up an API
> > that goes mostly unused in Emacs? Its only heavy user is ls-lisp.el,
>
> This patch also improves the performance of file-name-completion
> -- perhaps you missed that part?
I just didn't imagine that file-name-completion would need to call
'lstat'. But now I see that it does, even twice in a row -- only so
it could support FOO/ in completion-ignored-extensions. So perhaps a
further optimization would be to avoid the call to
file_name_completion_stat if completion-ignored-extensions is devoid
of elements that end in a slash.
> Better than that, w32 can model the POSIX file descriptor by
> using an int that represents the directory name.
Yes, this is indeed much simpler, thanks. I have only one comment:
> +static DIR *
> +open_directory (char const *name, int *fdp)
> +{
> + DIR *d;
> + int fd, opendir_errno;
> +
> + block_input ();
> +
> +#ifdef DOS_NT
> + /* Directories cannot be opened, so emulate an open directory with
> + its name, cast to a pointer. This is good enough for Emacs. */
> + fd = (int) name;
^^^^^
I think we should use ptrdiff_t rather than int here, since that could
make a difference in 64-bit builds on Windows.
next prev parent reply other threads:[~2013-01-28 14:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-24 8:26 bug#13539: Use fdopendir, fstatat and readlinkat, for efficiency Paul Eggert
2013-01-24 17:28 ` Eli Zaretskii
2013-01-28 8:34 ` Paul Eggert
2013-01-28 14:37 ` Eli Zaretskii [this message]
2013-01-30 0:56 ` Paul Eggert
2013-01-30 17:27 ` Eli Zaretskii
2013-02-01 6:42 ` Paul Eggert
2013-01-30 19:24 ` Stefan Monnier
2013-01-30 20:24 ` Eli Zaretskii
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=83obg9idab.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=13539@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
/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.