The change to awk version to mtime/stat has one more drawback: it adds multiple external process invocations, instead of just one for the initial variant. Also it’s worth to note that system(“prog”) invocation doesn’t just call prog directly but rather /bin/sh -> prog. Simply put, it’s slower.
Ah yes, you’re right. I hadn’t considered that – it’s fine in Python with a direct os.stat() system call, but yeah, it’s doing a ton more for each file in the AWK version (the shell + stat in AWK takes about 2ms per invocation, whereas the os.stat() call in Python takes about 1us per invocation – almost 2000x as fast). I can see why the AWK book used the ls -t method. I still don’t love how indirect it is, and that it won’t handle files in subdirectories, but it’s definitely more efficient.
Using ls -t is an excellent example of calling existing and well maintained API to sort the files by descending time modified. Usually I would ask for a detailed and convincing reason to replace it with an in-house reimplementation.
The change to awk version to
mtime/stathas one more drawback: it adds multiple external process invocations, instead of just one for the initial variant. Also it’s worth to note thatsystem(“prog”)invocation doesn’t just callprogdirectly but rather/bin/sh -> prog. Simply put, it’s slower.Ah yes, you’re right. I hadn’t considered that – it’s fine in Python with a direct
os.stat()system call, but yeah, it’s doing a ton more for each file in the AWK version (the shell +statin AWK takes about 2ms per invocation, whereas theos.stat()call in Python takes about 1us per invocation – almost 2000x as fast). I can see why the AWK book used thels -tmethod. I still don’t love how indirect it is, and that it won’t handle files in subdirectories, but it’s definitely more efficient.Using
ls -tis an excellent example of calling existing and well maintained API to sort the files by descending time modified. Usually I would ask for a detailed and convincing reason to replace it with an in-house reimplementation.