Re: Multibyte and unibyte file names

[Eli Zaretskii]

> Date: Sat, 26 Jan 2013 10:06:26 -0800
> From: Paul Eggert <address@hidden>
> CC: "Stephen J. Turnbull" <address@hidden>, address@hidden
> 
> On 01/26/2013 09:33 AM, Eli Zaretskii wrote:
> > directory-files-and-attributes, used on Windows
> > to emulate 'ls', must be fast enough even in large directories,
> > because otherwise Dired will be painfully slow to start.  As things
> > are, things are too slow already, especially with remote filesystems;
> > there were bug reports about this last year.
> 
> Is it possible that those performance problems are due to networking,
> or due to the OS overhead of repeatedly interpreting long file names
> (addressed for POSIXish systems by the proposed patch in Bug#13539),
> rather than due to the overhead of decoding file names retrieved
> from directories?

Sorry, I didn't mean to say that the performance problems are due to
decoding.  I meant to say that performance sometimes sucks even
without adding more decoding.

The performance complaints I heard last were due to retrieving owner
and group information from remote files.  That problem was hopefully
solved in trunk revision 111226.