[ On Wednesday, May 31, 2000 at 16:27:55 (+1000), Simon Burge wrote: ]
> Subject: field widths in ps(1).
>
> The main drawback for this is that it effectively runs through the
> process list twice - once to calculate the maximum field widths and
> another to display the results.  On my 166MHz PPro, this equates to 0.04
> seconds to show 73 processes with the old ps(1) and 0.06 seconds with
> the new.

Why would you do it that way?  I'm reasonably certain that if 'ps'
simply allocated enough memory to hold all of the information it needs
to formulate the report in binary form, and then slurped it all in at
once (perhaps allocating in chunks as it goes along reading the
information), and finally scanned through it as necessary to make the
report as pretty as possible, that there would in fact be no significant
slowdown and it would certainly be faster than "asking" the kernel for
the same information twice.  Yes, having 'ps' grow in size would
potentially cause some additional paging but certainly this would be
less of an impact on the system than going to the kernel twice,
especially for any report that causes paging in the first place.

Not to mention but that it would be more accurate as well -- the kernel
could easily change a value in such a way that it would make a field
wider, or narrower, between fetches.

> I just knocked up a "q"uick mode that doesn't do any column line-ups:

YES PLEASE!  I've been wanting that kind of more easily parsable output
for nearly a decade now, especially on BSD systems which were some of
the last to fix bugs that cause data columns to mush together
inseparably in so far as any text processing tool can tell (and in
NetBSD's case "vmstat" *still* does this!).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>