slachiewicz / caliper

Automatically exported from code.google.com/p/caliper
Apache License 2.0
0 stars 0 forks source link

Automatic convenience unit conversions e.g. nanos->millis #152

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Issue 75 talks about arbitrary unit conversions like nanos/rep -> kbps. That 
feature will be used relatively rarely, in special cases, when users write 
extra code to enable it.

*This* issue is about the more universal case, where you want caliper to 
perform just simple, lossless, scaling conversions just for convenience, like 
nanos->millis, bytes->KiB, etc.

I believe this should be treated purely as a display issue.  Caliper should 
just have knowledge of all the common conversions hardcoded (e.g. bps->Kbps 
means divide by 1000, etc.) That code would be used by the 
ConsoleDisplayResultProcessor and in the GWT app.  But, as far as the 
instrument is concerned, and the .json file, those always just use the same 
standard form (ns for micro, bytes for allocation and memory, etc.) (That's 
what is meant by "purely a display issue".)

The GWT app may or may not initially have UI to let the user explicitly change 
these.  But what it does need is the ability to choose a good unit 
appropriately. After thinking about it, I propose that it should choose the 
largest unit for which no measurement falls below <threshold> -- where 
threshold might be, for example, 1.0.

What should the console display do?  I really don't want to keep the old 
command-line option to specify the unit to use.  But we could let that be in 
.caliperrc.  And use the same default-choice as just described otherwise.

Original issue reported on code.google.com by kevinb@google.com on 8 May 2012 at 9:19

GoogleCodeExporter commented 9 years ago

Original comment by kevinb@google.com on 8 May 2012 at 9:20

GoogleCodeExporter commented 9 years ago

Original comment by kevinb@google.com on 1 Nov 2012 at 8:32

GoogleCodeExporter commented 9 years ago
For 1.0, this will always be ns and always be bytes.

Original comment by gak@google.com on 1 Nov 2012 at 9:04