Hi, Greg.
We've discussed this earlier.
Breaking news: /proc is slow, /sys too. Always have been.
Each /sys file is kind of fast, but there are so many files that
lookups eat all the runtime.
/proc files are bigger and thus slower. There is no way to filter
information.
If someone would post /proc today and said "it is 20-50-100" times
slower (which is true) than existing interfraces, linux-kernel would
not even laugh at him/her.
> slow in what way?
open/read/close is slow compared to equivalent not involving file
descriptors and textual processing.
> Text apis are good as everyone can handle them,
Text APIs provoke inefficient software:
Any noob can write
for name in name_list:
with open(f'/sys/kernel/slab/{name}/order') as f:
slab_order = int(f.read().split()[0])
See the problem? It's inefficient.
No open("/sys", O_DIRECTORY|O_PATH);
No openat(sys_fd, "kernel/slab", O_DIRECTORY|O_PATH);
No openat(sys_kernel_slab, buf, O_RDONLY);
buf is allocated dynamically many times probably, it's Python after all.
buf is longer than necessary. pathname buf won't be reused for result.
.split() conses a list, only to discard everything but first element.
Internally, sysfs allocates 1 page, instead of putting 1 byte somewhere
in userspace memory. /proc too.
Lookup is done every time (I don't think sysfs caches dentries in dcache
but I may be mistaken, so lookup is even slower).
Multiply by many times monitoring daemons run this (potentially disturbing
other tasks).
> ioctls are harder for obvious reasons.
What? ioctl are hard now?
Text APIs are garbage. If it's some crap in debugfs then noone cares.
But /proc/*/maps is not in debugfs.
Specifically on /proc/*/maps:
* _very_ well written software know that unescaping needs to be done on pathname
* (deleted) and (unreachable) junk. readlink and /proc/*/maps don't have
space for flags for unambigious deleted/unreachable status which
doesn't eat into pathname -- whoops
> I don't understand, is this a bug in the current files? If so, why not
> just fix that up?
open/read DO NOT accept file-specific flags, they are dumb like that.
In theory /proc/*/maps _could_ accept
pread(fd, buf, sizeof(buf), addr);
and return data for VMA containing "addr", but it can't because "addr"
is offset in textual file. Such offset is not interesting at all.
> And again "efficient" need to be quantified.
* roll eyes *
> Some people find text easier to handle for programmatic use :)
Some people should be barred from writing software by Programming Supreme Court
or something like that.
