Description
Some brainstorming about ways es' time
builtin could be improved:
-
More precise -- 0.1s is way too large a time quantum to be useful on modern machines, and 1s (for the real-time measurement) is absurd. I find myself running
bash -c 'time es -c ''blah'''
just to get meaningful timing output, which seems wrong. Milliseconds is probably most appropriate for a shell. -
Custom formatting -- It could be nice for
$&time
to simply return a list of(real user system)
, and havetime
decide how to format it. We could also have%time
in the middle to get a "three-layer" setup likevar
orwhatis
.time
could be changed to change how times are printed, and%time
could be changed to change how times are collected. Then, with a hookabletime
, you could keep the current whole-seconds and tenth-of-seconds printed formatting despite a more precise$&time
if you wanted to maintain the current behavior :) -
Forkless -- Speaking of changing how times are collected, it seems to me that with both
getrusage()
andtimes()
, we don't actually need to fork a new process to get a measure of the running time of a block. This is very interesting; whole scripts could be broken up into chunks wrapped intime
calls to find slow sections, without changing the functionality of the script at all. This would also, for example, allow the example of hookingtime
into%pipe
in the old es paper to be extended to other control flow constructs. Heck, you could hooktime
into%dispatch
,%seq
, orforever
without breaking anything! With a hookabletime
and%time
as described above, you could also wrap the timed command in afork {}
if you wanted to maintain the current behavior :)