On Sat, Jan 08, 2000 at 04:19:09PM -0800, david parsons <orc@pell.portland.or.us> wrote:
> Admittedly, in the case where you start top and lean on the spacebar
> it would be faster, but it seems like having top refresh 30+ times a
> second would be wasting 29+ of those refreshes.
Well, everybody judges the usefulness of top differently. But I think a
time of 350ms (which is about 12 million processor cycles and much more
instructions) is waaay too long to display a few task statistics.
> takes 0.99% of the processor. And on the Celeron/338 I'm using as a
> workstation, it takes a princely .098% to do the same.
Are you sure that you are measuring this correctly? This is a serious
question: cpu time measurements are very incorrect (at least under
linux). My very crude measurement gives a lower bound (module system
load).
> of the badly designed proc displays which can't officially change
> but which do change enough to make upgrading to a new release
> a little more annoying] but performance doesn't leap out and
> grab me.
Then have a look at what people run on their desktops. Have a look at how
many people can be logged on to a machine, all with their desktop. These
very small times quickly sum up to a substantial amount of time.
As it is, /proc gives hundreds of pieces of information scattered about
many places, in a very inconsistent way (for example, how can I find the
statistics of my fifth harddisk? I can't find a place in proc...).
/proc is a nice place for things like cpuinfo, modules, partitions, uptime
and much more. But I fail to see the advantage of information that can
only be parsed by specialised programs ("number graves") anyway to be
published in /proc, so that it is ultra-slow to access.
-- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:13 EST