On 15 Oct 1996, Stephen J. Alexander wrote:

> I can think of a few reasons right offhand. The first thing is, the resources
> being consumed aren't because the program has to spit out a few extra
> characters per line, but because it has to go through the permission bits and
> decide what's what then display them. It's the same reason ls -F is so damned
> slow. Another reason could be that it's just not well coded, though if it's
> gnu, I'd have to doubt that.

Unless the interface to get the permissions bits is ridiculously slow,
though, it shouldn't take very long to look at three bits and, if they're
turned on, display it as an executable, if not, check the .txt or .jpg or
whatever ending, display it as whatever color....  I still suspect that
the majority of the slowdown is in the hardware doing the display of the
color ls rather than in the software dumping the vt100 codes.

But then, I don't know how long it takes to get the permissions bits.  I
would think that it would all come up in the dirent structure for the
file, right?  Is my terminology right?  In which case, it shouldn't take
any extra time whatsoever to get the permission bytes, split the bits up
with a simple...

for (n=7;n>=0;n--){
	bit[n]=byte%(2^n);
	if bit[n] then byte=byte-2^n;
	}

Then check the appropriate bits.

Thoughts?

 /---------------------------------------------------------------------\
|David A. Gatwood             And Richard Cory, one calm summer night,  |
|davagatw@mars              Went home and put a bullet through his head.|
|dgatwood@nyx.cs.du.edu              --Edwin Arlington Robinson         |
|http://mars.utm.edu/~davagatw -or- http://nox.cs.du.edu:8001/~dgatwood |
 \---------------------------------------------------------------------/