[ On Friday, June 2, 2000 at 11:44:21 (+1000), Simon Burge wrote: ]
> Subject: Re: field widths in ps(1). 
>
> and the same for 100 "ps aux > /dev/null"s on the same machine with 30
> copies of the C program "main() { while (1) ; }" running (sample of 9
> runs):
> 
> 	old: 5.233u 5.439s 3:21.12 5.3% 0+0k 0+125io 0pf+0w
> 	old: 3.103u 7.500s 3:34.02 4.9% 0+0k 0+111io 0pf+0w
> 
> 	new: 7.001u 3.632s 3:22.03 5.2% 0+0k 0+106io 0pf+0w
> 	new: 6.091u 4.463s 3:28.83 5.0% 0+0k 0+122io 0pf+0w

That does look a lot better....

How about comparing 100 (or 500, or even 1000) copies of "sleep 30000 &"
running vs. none, again with 10 or more samples averaged?  That should
give you a good idea of how long it takes to do the extra processing per
line.

Maybe do separate timings of "ps -ax", "ps -aux", and "ps -alx" too...

> At this stage I'd guess that when the machine is under very heavy load,
> the exec overhead is probably greater than any extra processing my
> changes to ps does.  When the 30 cpu burners were running, even typing
> at the shell was painful...

could be....

> As to optimising the width calculations, currently it does for doubles
> and ints something like:
> 
> 	if (mode == WIDTHMODE) {
> 		asprintf(&buf, "%.*f", prec, val);

I was think it could do something even smarter that simply looked at the
magnitude of the number knowing what base and format it would be
converted into and didn't go about doing any actually conversions....

For example when converting to hex it's trivial to figure out how many
digits you'll need.  For decimal numbers it's a bit harder, and I'm not
sure if I'd want to tackle doing floating point in fewer CPU cycles than
an actual conversion would take....

Of course for some non-numeric fields (eg. the start time, percentages,
etc.) it's probably sufficient to hard-code the width.

-- 
							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>