[patch][ccla] Step profiler

[[email protected]…]

Attached is code and tests for a step profiler, as dojo.profile.StepProfiler?. This is a global profiler which records the time since the previous step against the profile. You can then get results as an array or printed using dojo.debug.

Multiple profilers can be set up and act independently, and because the global profiler stores the data, a single profile can be 'stepped' in different functions without passing a variable around.

It is a really useful means of figuring out where time is spent in a process during development and testing.

It basically works as follows (there are more abilities but this is most of it):

function myFunc() {
  // in this case our profile is called 'prof'
  dojo.profile.StepProfiler.start("prof", "start");
  ... do something ...
  dojo.profile.StepProfiler.start("prof", "step 1");
  ... do something ...
  dojo.profile.StepProfiler.start("prof", "step 2");
  ... do something ...
  dojo.profile.StepProfiler.start("prof", "step 3");

  // print the results via dojo.debug
  dojo.profile.StepProfiler.print("prof");

  // get them as an array
  var profileResults = dojo.profile.StepProfiler.toArray("prof");
  // profileResults: [["start", 0], ["step 1", 8], ["step 2", 106], ["step 3", 1]]
}

printed results:

DEBUG: StepProfiler - prof:
DEBUG:   start:
DEBUG:   step 1: 8ms
DEBUG:   step 2: 106ms
DEBUG:   step 3: 1ms

[[email protected]…]

initial patch

[[email protected]…]

initial patch

[[email protected]…]

everything is repeated in the first patch (TortoiseSVN has 'issues' sometimes), so use the 2nd 'initial' one :)

[alex]

might it be a better API to return a "stepping" object that would allow you to remove some of the redundancy in the step calls? I like the idea...I kinda wonder if it could be rolled into the current profiling code without many changes or if they're too different. I'd hate to not have a unified API location for it.

[[email protected]…]

might it be a better API to return a "stepping" object that would allow you to remove some of the redundancy in the step calls?

That was my initial plan, but passing things through attached event handlers and callbacks is not neccessarily fun, so I deliberately went with the global registry. For cases like that people (me) are much less inclined to profile if they have to pass objects around through half a dozen methods.

But for simple cases, it does make sense. Maybe a hybrid where the calls return an object which you can then call step() on again - but its just a reference to the global profile?

[[email protected]…]

Ok, new patch.

start() now returns an object you can call step(), print(), toArray(), and reset() on. The same profile is still accessible from the global methods.

Tests have been updated to suit (not that I can run them in the harness because 'ant test' hangs after umpteen failures in other code).

[[email protected]…]

New patch where start() returns an object with methods.

[[email protected]…]

I kinda wonder if it could be rolled into the current profiling code without many changes or if they're too different. I'd hate to not have a unified API location for it.

Any suggestions on this? The current dojo profile code enables you to run a function a lot of times and then prints the results.

For tying into functions and seeing where time is spent there is the Firebug profiler, but seeing that getComputedStyle() is using 50% of the time unfortunately doesn't help find where.

This is the 3rd tool in my arsenal for finding which blocks of code to focus on and run the other tools against.

[dylan]

This probably makes sense in a dojox package as it does provide capabilities that you don't get with Firebug. Robert, what are your plans currently for this?

[Robert Coup]

I have actually ported it to 1.x already so I'll package it a bit more nicely for dojox. Is there anything from the 0.4 dojo.profile stuff that should be ported as well?

Ideas on a package name? dojox.profile? dojox.devtools?

[dylan]

I think the other stuff was pretty redundant with what Firebug provides, but if you feel otherwise, feel free to port that as well.

I was always a bit annoyed with dojo.profile because it was confusing because of dojo's build system profiles.

How about dojox.performance? devtools seems fine to me as well.

[guest]

As a developer working on legacy "IE only" applications, Firebug is not an option. I would love to see some performance testing tools in dojo. I realize this is an edge case, but just know there are people out here that would love some of firebug's goodness in a cross browser way.

[dylan]

@guest: firebug lite which ships with dojo does help with some of this, but yes, we need to pick up where it leaves off.

[bill]

defer dormant enhancements to "future" (they don't look like they're getting fixed soon so might as well mark as such)

[ben hockey]

i'm trying to identify stale tickets. if there is a need to keep this ticket open, please replace the "needsreview" keyword with "reviewed". if there is no need to keep this ticket open then please close it.

[dylan]

Suggestion is to just use DynaTrace? at this point. Closing as wontfix.