For OP's use case, which appears to have a max depth of maybe 3, invoking a shell program is going to be a LOT slower than just running the search. No matter how slowly it is implemented.
For OP's use case, which appears to have a max depth of maybe 3, invoking a shell program is going to be a LOT slower than just running the search. No matter how slowly it is implemented.
You are basically saying the whole UNIX philosophy of specialised reusable programs chained together is a flawed design.
Spawning a program is not slow. Store the programs file arguments on a ramdisk to avoid disk IO and there will be no noticeable overhead.
Reusable piped programs are great for some things, especially a productive shell language. No, composing processes is not great for all things, and certainly not where performance is required. This is why FreeBSD is a monolithic kernel instead of a microkernel with processes, for example.
Spawning a program is incredibly slow, even ignoring disk read times, compared to 3 levels of low-branch-factor search in any language.