Skip to content

time could be improved #154

Open
@jpco

Description

@jpco

Some brainstorming about ways es' time builtin could be improved:

  1. 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.

  2. Custom formatting -- It could be nice for $&time to simply return a list of (real user system), and have time decide how to format it. We could also have %time in the middle to get a "three-layer" setup like var or whatis. time could be changed to change how times are printed, and %time could be changed to change how times are collected. Then, with a hookable time, 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 :)

  3. Forkless -- Speaking of changing how times are collected, it seems to me that with both getrusage() and times(), 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 in time calls to find slow sections, without changing the functionality of the script at all. This would also, for example, allow the example of hooking time into %pipe in the old es paper to be extended to other control flow constructs. Heck, you could hook time into %dispatch, %seq, or forever without breaking anything! With a hookable time and %time as described above, you could also wrap the timed command in a fork {} if you wanted to maintain the current behavior :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions