Opened 13 years ago

Closed 6 years ago

#1827 closed enhancement (wontfix)

[patch][ccla] Step profiler

Reported by: robert.coup@… Owned by: Robert Coup
Priority: low Milestone: future
Component: Dojox Version: 0.4
Keywords: needsreview Cc:
Blocked By: Blocking:

Description (last modified by ben hockey)

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

Attachments (3)

step_profiler.patch (11.3 KB) - added by robert.coup@… 13 years ago.
initial patch
step_profiler.2.patch (5.7 KB) - added by robert.coup@… 13 years ago.
initial patch
step_profiler.3.patch (5.7 KB) - added by robert.coup@… 12 years ago.
New patch where start() returns an object with methods.

Download all attachments as: .zip

Change History (18)

Changed 13 years ago by robert.coup@…

Attachment: step_profiler.patch added

initial patch

Changed 13 years ago by robert.coup@…

Attachment: step_profiler.2.patch added

initial patch

comment:1 Changed 13 years ago by robert.coup@…

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

comment:2 Changed 13 years ago by alex

Owner: changed from anonymous to alex
Status: newassigned

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.

comment:3 Changed 13 years ago by robert.coup@…

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?

comment:4 Changed 13 years ago by alex

Milestone: 0.5

comment:5 Changed 12 years ago by robert.coup@…

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).

Changed 12 years ago by robert.coup@…

Attachment: step_profiler.3.patch added

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

comment:6 Changed 12 years ago by robert.coup@…

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.

comment:7 Changed 12 years ago by alex

Milestone: 0.91.1

comment:8 Changed 11 years ago by dylan

Component: GeneralDojox
Milestone: 1.11.2

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?

comment:9 Changed 11 years ago by Robert Coup

Owner: changed from alex to Robert Coup
Status: assignednew

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?

comment:10 Changed 11 years ago by 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.

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by 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.

comment:13 Changed 11 years ago by bill

Milestone: 1.2future

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

comment:14 Changed 7 years ago by ben hockey

Description: modified (diff)
Keywords: needsreview added
Priority: highlow

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.

comment:15 Changed 6 years ago by dylan

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.