[throwaway0094]

> Its been tuned over years for use in competitions. So it probably runs faster than the author's, even though it has more features.

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.

[tlarkworthy]

"Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

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.

[anonymouscowar1]

Are you kidding me? This is pretty fucking arrogant. My $DAYJOB is FreeBSD kernel hacking.

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.

[nn3]

Your suggestion is the morale equivalent of asking to install Oracle for a simple "tiny data" database problem when sqlite or just a hand crafted table is far enough.