-
Notifications
You must be signed in to change notification settings - Fork 108
Open
Labels
P4component: web uistatus: acceptedtype=enhancementMake an existing feature betterMake an existing feature better
Milestone
Description
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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
P4component: web uistatus: acceptedtype=enhancementMake an existing feature betterMake an existing feature better