GNU bug report logs - #44273
"total used in directory 19 available 5.2 GiB"

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: mattiase <at> acm.org, 44273 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: bug#44273: "total used in directory 19 available 5.2 GiB"
Date: Wed, 28 Oct 2020 17:28:45 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 28 Oct 2020 12:02:06 +0100
> Cc: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
>  44273 <at> debbugs.gnu.org
> 
> The argument that Tramp needs to parse "ls" output is valid, and that
> "ls" is faster than `ls-lisp' is, too, but it's still backwards: Dired
> should take a well-defined data structure and then render it according
> to however the user wants.

I think it would be useful to measure the difference in speed between
ls-lisp and 'ls' the program on various platforms.  For example, use
benchmark-run to time (dired "foo") with some large directory 'foo',
with and without ls-lisp loaded.  (This should be done with a warm
disk cache.)  This should tell us how badly we need to speed up
ls-lisp.

Profiling ls-lisp could also be educational.  For example, I see in
the profile on my system that this loop:

	(let ((locale system-time-locale))
	  (if (not locale)
	      (let ((vars '("LC_ALL" "LC_TIME" "LANG")))
		(while (and vars (not (setq locale (getenv (car vars)))))
		  (setq vars (cdr vars)))))

is run for each file, which is definitely a waste of cycles.  My
measurements indicate that running this loop just once could speed up
ls-lisp by 25%.

> The data can come from `ls-lisp', but it could also come from "ls": We
> just need to write a parser that parses the data.

The data which comes from 'ls' can take many different formats,
depending on the switches.  Parsing each and every one of them sounds
daunting.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.