Re: Possible speedup?

[Kai Grossjohann]

Skip Montanaro <address@hidden> writes:

> As you can see, the number of file-attribute calls it makes is proportional
> to the depth of the path to the file being saved.
>
> Would it be possible to collapse that into a single "super-file-attributes"
> call which did all of the nested file-attributes calls during a single
> request?  It could then pass all that information back as an aggregate where
> the normal "file-attributes" function can extract them.

Hm.  Tramp is being invoked with file-attributes only, so it would
have to figure out how to remember the right calls.  Hm.  Oh, if it
really reads bottom to top then that means that Tramp starts with /a,
followed by /a/b, then /a/b/c, and so on.  So it can't know on the
first call which subsequent calls will be needed.

The whole thing probably comes from the *-truename variables.  You
could try setting them to nil to see if that changes something.

> I'm sure there are other ways of accomplishing this.  I don't understand the
> tramp code well enough to speculate, but it seems like it would be a big
> improvement over the status quo.

If my idea about *-truename is correct, then it might help to rework
tramp-handle-file-truename.  Are those calls to file-attributes coming
from tramp-handle-file-truename?

> On a related note, why is using ls to fetch file attributes not preferred
> over using perl?  I suspect it would be faster.

The Perl script knows how to find out the exact timestamp.  Since the
timestamps returned by ls -l are so imprecise, I currently told Tramp
to ignore them.

I guess that there are quite a number of machines with a stat or fstat
program, which could be used.  I asked around for different stat
programs and how to parse their output, but nothing ever came out of
it.  That is, people responded but I didn't do anything with that
information.

Does anyone want to work on this?

Kai