Simplify $&time and increase its flexibility#210
Open
jpco wants to merge 12 commits intowryun:masterfrom
Open
Conversation
- Clean up time code to be much more legible - Use intmax_t for timestamps to be more overflow-resistant - Add fallback for time functions - Add error handling
This uses the (AFAICT) previously-unused 'dotconv' for a new purpose. If an integer (for example, 8675309) is printed with "%.3d", the output is 8675.309, putting three decimal places after the point. This is a bit weird, but it avoids any complexity around non-integer numbers.
Collaborator
Author
|
I fixed the negative-number-printing issue. Yay! Now I feel good about actually proposing this for merging. However, a possible nitpick now is on the question of how to pad times accounting for the extra digits. Currently the new shell ( However, this sure isn't very much padding anymore, so it might be reasonable to bump the padding values up by a couple characters. |
64361a8 to
a23a7a0
Compare
Collaborator
Author
|
Tidied up this PR after #226. It's just 30 net lines added now, including the 10 lines added for the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR changes the
$&timeprimitive and thetimefunction. It fixes #154.Previously, the basic steps of
$&timewere: (1) measure real time and usage times; (2) run the given command; (3) measure real times and usage again; (4) take the difference and print the result.We now shrink the scope of
$×o that takes an optional previous set of times as arguments, and it (1) measures the real and usage times, (2) subtracts the argument-times if given, and (3) returns the result. Like this:The built-in
timefunction is constructed from this new$&timeas:Benefits of this new setup:
timenow reports millisecond precision timing, instead of second/tenths-of-seconds. On those few systems which don't support more precise timing methods, we fall back gracefully to the worse but very standard functions.timeuses straightforward es control flow and does not fork. Because of this,timecan be used "transparently";time {a = b}; echo $anow does the expected thing. A user could wrap one part of a script within atime {}without screwing up the semantics of the timed section.timeto fork, that can be done by changing thetimefunction.let ((s _) = <=$&time) echo $sapproximates thetimescommand in other shells.We can also do some, err, mild hackery to measure "has it been more than $X?" This can be used for testing performance of certain constructs (e.g., on #213), or for something like
In theory, the same thing could be done with
date +%s, but that would potentially add a lot of fork-exec overhead to gather and do math on all the timestamps. This way also works around es' lack of general arithmetic support, and supports quite a bit of precision.One limitation of the new
$&timeandtime: Across es invocations, results get wacky with the timing measurements, and across processes (likefork {}) results get wacky with usage times specifically.