I added more decimal digits to the timing statistics counters #1106

Open
wants to merge 1 commit into
from

Projects

None yet

4 participants

@maurorappa
maurorappa commented Nov 4, 2016 edited

in order to provide more detailed performance statistics, I changed the printf to use 6 decimals.
Luckily enough the metrics were already using double integers.

maurorappa I added more decimal digits to the timing statistics counters, in ord…
…er to provide more detailed performance statistics
9615d3a
@mention-bot

@maurorappa, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bagder, @gevaerts and @yangtse to be potential reviewers.

@bagder bagder added the cmdline tool label Nov 5, 2016
@bagder bagder added a commit that closed this pull request Nov 5, 2016
@bagder Mauro Rappa + bagder curl -w: added more decimal digits to timing counters
Now showing microsecond resolution.

Closes #1106
ebeffe8
@bagder bagder closed this in ebeffe8 Nov 5, 2016
@bagder
Member
bagder commented Nov 5, 2016

thanks!

@jay
Member
jay commented Nov 5, 2016

Could this conceivably break some scripts if they expect data in a 0.000 and is microsecond really necessary for those statistics? All I get is a lot of x.xxx000

@maurorappa

This is my output on Ubuntu Trusty:

maurorappa@trusty:~/curl/src$ ./curl -sLk -w "%{http_code}\n%{time_total}: %{time_namelookup} %{time_connect} %{time_appconnect}\n%{speed_download} %{num_redirects}\n" https://dcs.ida.digital.cabinet-office.gov.uk -o /dev/null
400
0.083220: 0.067998 0.069151 0.082273
2956.000 0

I can do statistical analysis of the SSL performance with more granularity.

@jay
Member
jay commented Nov 5, 2016

Ok. time_total is documented as millisecond resolution so that's something we have to consider. And I suspect it becomes somewhat more arbitrary after that since it's basically wall clock time. What if there was a variable like %{flags:microseconds,foo,bar}

@bagder
Member
bagder commented Nov 5, 2016

Ah yes good catch, time_total does in fact have that mentioned in the docs. I consider that a bug though and no other time variable has that detail mentioned.

@maurorappa

I can fix the man page if it helps.

@bagder
Member
bagder commented Nov 5, 2016

Yes please, the millisecond mention is wrong now since commit ebeffe8

@jay jay added a commit to jay/curl that referenced this pull request Nov 8, 2016
@jay jay tool_writeout: add %{flags:} param. draft1
- Add %{flags:<flag>,...} to --write-out

- New write-out flag stderr to redirect to stderr

- New write-out flag moreprec to increase precision from 3 to 6

---

This is an alternative proposal to adding more precision by default.
curl#1106
e1d063b
@jay
Member
jay commented Nov 8, 2016

I think we should not do this by default, and that adding it as an option would be better. To that end I've written a counterproposal, you can see it at https://github.com/curl/curl/compare/master...jay:add_flags_to_write-out?expand=1

curld -sS --write-out " %{time_total} %{flags: moreprec,stderr} %{time_total}" example.com -o NUL 2>NUL
 0.047

curld -sS --write-out " %{time_total} %{flags: moreprec,stderr} %{time_total}" example.com -o NUL 1>NUL
 0.047000
@bagder
Member
bagder commented Nov 8, 2016

I think we should not do this by default

Because of the risk that it will break some scripts? Because some machines won't have better accuracy than milliseconds anyway?

What about inventing some additional syntax hint that allows users to specify precision per variable. like %{time_total@6} and %{time_total@3} ?

@bagder bagder reopened this Nov 8, 2016
@jay
Member
jay commented Nov 8, 2016

For all those reasons, but also with respect to the reporter measurements based off of differences in wall clock time are only so accurate. Your way is interesting, however I like the idea of %{flags regardless because it's extensible

@jay jay added a commit to jay/curl that referenced this pull request Nov 28, 2016
@jay jay tool_writeout: add %{flags:} param. draft2
- Add %{flags:<flag>,...} to --write-out

- New write-out flag 'fd[1-9]|stderr|stdout' to write to a specific fd

- New write-out flag 'prec[0-99]' to increase precision of floats

---

This is an alternative proposal to adding more precision by default.
curl#1106
6ee96e4
@jay
Member
jay commented Nov 28, 2016 edited

I just finished draft2 of this, if the feature window hasn't closed yet and there is interest. I still need a test.

flags Flags to alter behavior. (Added in 7.52.0)

'prec[0-99]' Use this precision in floating point values instead of 3. Note if
your OS doesn't support the higher resolution then all zeroes may be output for
the extra digits, eg 0.047000 (Added in 7.52.0)

'fd[1-9]|stderr|stdout' Write the output to a file descriptor instead of the
default stdout. Note stderr isn't recommended since it is used for errors and
there's a possiblity an error may disrupt the write-out text. Also this is not
entirely portable; whether it works depends on your shell and build of curl.
(Added in 7.52.0)

Each flag can be used multiple times and at any point in the write out text
unless otherwise stated. To use the flags variable follow it with a colon and
zero or more flags separated by a comma, optional whitespace (ignored) and
optionally prefixed by a modifier. An unprefixed or + prefixed flag is turn on
and a - prefixed flag is turn off. For example %{flags: stderr, -prec6}.

Conceivably in Linux and cygwin it should work on 3>foo and if %{flags:fd3} the write-out text will go there. It won't work in Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment