Albert D. Cahalan wrote:
> I'd love to have the binary structures for C. In spite of being
> 100% C, "top" can use 50% of my CPU time. Real code is C anyway.
The performance issue here is /proc/<pid>. All the other entries
people keep on complaining about have only marginal relevance for
performance.
> Nope, most /proc access is does via programs written in C.
That varies a lot from file to file. E.g. I haven't seen any programs
that are specificly designed to read /proc/atm/* yet, and I know of
only one (fuser) that reads /proc/mounts, extracting only partial
information (just to pick two examples that I'm quite familiar with).
Also, what are all the integrated system administration tools (linuxconf,
etc.) written in ? I wouldn't be surprised if many of them are written
in some scripting language. So they'd have to access that information via
the dedicated utility written in C. Are you sure
binary-interface -> utility -> parser-in-script-language
is really superior to
/proc -> parser-in-script-language
? (Throw in internationalization to make things even messier.)
> The /proc/*/status keyword SigCat was changed to SigCgt.
> This is fine for a human, but programs shouldn't have to deal
> with this. Plain text in /proc costs you both reliability and
> performance.
Are you suggesting that you would find it easier to handle inconsiderate
changes to binary structures ?
A better example would be /proc file fields that contain tabs, spaces,
or newlines. This is a real problem. A clean solution would be a
function that turns such names into valid C source strings, with blanks
escaped too e.g. "this\tis\nhard\200to\040parse"
(there are several other reasonable alternatives).
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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 : Tue Feb 29 2000 - 21:00:10 EST