I follow, back in a previous life, in a previous profiler we had this concept of "sub steps", the idea was to have light weight counters that aggregate times, just as you describe.
I would love to see this kind of support in MiniProfiler as well.
The concept would be to add say:
Rack::MiniProfiler.counter("counter name") do
# stuff goes here
Then the UI can have special handling for counter steps, and add the column dynamically. I think this will work fine, but am a bit concerned about what happens when there are say 50 different counters, the UI will get terribly wide. I don't think this is blocking though, we can figure out a solution once we have that problem.
We also need to be extra careful implementing the counter API, as this is meant to be extra light weight.
Love the idea, and would be more than happy for you to work on it in a fork.
Word of warning though, I think it is time for some prep work to add a proper object model for the mini profiler data, at the moment it is using a really odd object semantics that is a relic of the mini profiler ruby prototype.
Every time I see code like this I cringe:
def initialize(name, page, parent)
super("Id" => MiniProfiler.generate_id,
"Name" => name,
"DurationMilliseconds" => 0,
"StartMilliseconds" => (Time.now.to_f * 1000).to_i - page['Started'],
"ParentTimingId" => nil,
"Children" => ,
"KeyValues" => nil,
"TrivialDurationThresholdMilliseconds" => 2,
"SqlTimings" => ,
"Depth"=> parent ? parent.depth + 1 : 0,
@children_duration = 0
@start = Time.now
@parent = parent
@page = page
The objects should be pure, cause it also reduces the string allocations of MP and makes it more efficient, the serilizer can take care cleaning this up.