Warp wrote:
>   Yet there are plenty of resource monitors which can show cpu usage,
> bandwidths, memory usage, disk usage, and lots of info on a per-process
> basis ('top' being the basic example).

But that's peeking into the current system tables. Seeing what it is 
right now is easy. Reliably recording it moment by moment needs more, 
methinks.

If saying "hey, I just called sbrk() for another page of memory" or "I 
just did six I/Os to satisfy a select query" was as easy as sending 
something to syslog, I expect a lot more libraries would implement those 
sorts of measurements. As it is, there's no good place for the C runtime 
(for example) to record the max memory used, and no easy way to look at 
it when it's done. So adding this capability needs the implementor not 
only to record how much memory was used, but to write a program to 
display the histogram, to decide on a file format to use, to build the 
configuration subsystem to say what file it should go into, etc. And if 
it's something in the kernel, you have to probably build a device driver 
to turn it on and off, etc.  Probably seems like a lot of work.

Of course, I'm just guessing at a reason.

Say, did you try things like Purify? Shouldn't that be able to track it, 
since it replaces malloc and free?

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message