Currently you run loc, it prints its result and exits. You could add a kind of interactive mode:
% loc -i
>loc
[prints a count of lines in the usual format]
>loc
[rechecks the current directory and prints a new count]
>exit
%
The second count would be faster because it will remember the timestamp of the files it read last time, and not bother re-reading them if the timestamp has not changed. Even without that caching, there will be a saving on startup overhead compared to running the executable twice.
The envisaged use is for getting a history of line counts over several commits in a version control system such as git. Currently you can check out one revision, run loc, check out the next, run loc again, and so on. It would be faster if loc stayed running and could be poked to recompute the count of lines, without having to scan all the files that haven't changed between the two revisions.
Currently you run
loc, it prints its result and exits. You could add a kind of interactive mode:The second count would be faster because it will remember the timestamp of the files it read last time, and not bother re-reading them if the timestamp has not changed. Even without that caching, there will be a saving on startup overhead compared to running the executable twice.
The envisaged use is for getting a history of line counts over several commits in a version control system such as git. Currently you can check out one revision, run
loc, check out the next, runlocagain, and so on. It would be faster iflocstayed running and could be poked to recompute the count of lines, without having to scan all the files that haven't changed between the two revisions.