Linux Technical Debt: A Visual Explanation (Directory Entries/struct dirent) - Jody Bruchon Tech 

@@Error42_ That depends heavily on how you're doing it. Some ways can result in massive forking or reopening. I'd do it with find -type f > list.txt But you can extremely slowly do it with find -type f | while read -r X; do echo "$X" >> list.txt; done This will cause every entry to open, seek, write, and close, and if echo isn't a shell builtin it'll also cause a fork-exec every time too.

Many years ago I searched for a good software for technical drawing, and after a long search came to conclustion, that it doesn't exist. Nothing surpasses a piece of physical paper with a pencil and an eraser. And the process of physical drawing activates technical imagination like nothing else do.

I don't understand what you're trying to say.

@@JodyBruchon if the structure was an opaque data type, accessible only via functions, one could change the implementation of the string (also opaque) from a zero-terminated string to a counted string (length-prefixed), also changing a length function from a loop to a simple field access (and an optimizing compiler could inline it), without impacting programs that use this interface (at least at the source level).

@@s.b.8704 But that would add tons of function call overhead to what currently is just a pointer reference.

​@@JodyBruchon it shouldn't, especially if the function is simple. At least with GCC and Clang, already at -O1 the function call disappears and the field access code is replaced inline. There is no difference between the code that the compiler produces for direct access to structure fields and access via a function. Try this in Compiler Explore (godbolt, if only YT would let me post a link…), choose C and x86-64 gcc or clang and put -O1 as argument to the compiler: [quick&dirty code: of course structure "S" is not really opaque here and even less the string "c", I just want to compare direct field access and via functions with less possible code.] #include #include typedef struct {float a; long int b; int len; char *c;} S; char *sc(S s){ return s.c; } int sl(S s){ return s.len; } int main(int argc, char *argv[]) { S s; s.c=argv[1]; s.len=strlen(argv[1]); printf("s.c: %s ", s.c); // 1 printf("s.c: %s ", sc(s)); // 2 printf("Length of string s.c = %lu ",strlen(s.c)); // 3 printf("Length of string s.c = %d ",sl(s)); // 4 return 0; } The assembly code produced for 1 and 2 is the same, no function call for 2. The code produced for 3 and 4 is different: in 3 it calls strlen but no function call for 4 (move the cursor over the assembly code and the corresponding C code will be highlighted). Note that if you want to execute the code, in source frame select "+Add new..." menu, add "Execution Only" and write a string for execution argument (argv[1]).

@@s.b.8704 If the structure is really opaque, the compiler will not be able to inline access as you describe. Linker optimization could inline the code, but the kernel is not just one big executable.

@@Visentinel Because they're not going to care.

@@JodyBruchon not with that attitude they won’t, you need to actually write it up and send it first to find out if they would.

Changing this structure requires a lot more work than you can imagine. A new syscall would have to be made, glibc would have to be modified to use it, and user software would have to be modified to use d_namlen when available instead of strlen, plus this ignores all compatibility issues. The ship sailed on this in 1995 when Torvalds shot down d_namlen completely. The changes needed to fix it are so invasive that it's almost certainly not worth it.