Develop perf #612

wants to merge 17 commits into


None yet

3 participants


This code provides two things.

  1. A framework for logging debugging and performance metrics data on a per request basis.
  2. Some instrumentation of the core mojito code, using this api.

To use this results of this system you will also need the npm package, mojito-debug-view. This will be released separately.

Bret Thaeler and others added some commits Sep 10, 2012

return !!store.modules[flag]; should be just enough.


In mojito-perf we use a different technique to avoid doing all the "id" computation everywhere, something that is subject to change in the future. What we do is to pass command or a string. If command is passed, internally we know how to get the ID from the command structure.

Check idFromCommand in perf.server.js

So, this line will become something like:

adapter.debug.profOpen("dispatch", command.instance.debugID, command);

profOpen is a general purpose profiling API. It is called in several places. We don't want to pass command in here.

We can create a new function in the api to do this, we can mirror what perf.server.js does.

adapter.debug.profOpen("dispatch", command.instance.debugID, adapter.debug.idFromCommand(command));


I don't like this API because not all elements in mojito will have access to adapter obj. That's one of the reasons we use Y.mojito.perf.* as something that is available at any given time, without requiring it.

Really the API is attached to the req object. This is done by the debug middleware that detects that the debugger should be turned on. The existing mojito.perf system is only useful for a single request. If you have multiple requests occurring at the same time the results will get all merged together. By attaching the debugger to the request we can keep all the data separate. This needed when we look towards running this in a production environment.

caridy commented Oct 11, 2012

This PR is very long and confusing, probably because there is a mix of old code with new code, and refactors in the middle, I will need more time to make sense of it.

I do have few questions already:

  • How does this work on client side?
  • How a model for example, can have access to debugger?
  • How does this work with the current perf api? They clearly overlap, one of them have to be blended.

The intent is to eventual make this api work on both the client and server side. We should be able to get the Debug UI to merge both server side and client side results together. This is a feature we plan to work on next quarter.

To use the debugger in a model, one would need to pass down debugger to the getData methods in the model.

The code does work woth the current perf api. If you enable perf marks, prof.PerfMark will be an available debug flag. The results will appear in a water fall display.

caridy commented Oct 12, 2012

@bthaeler let's have a quick meeting to talk about this PR. /cc @drewfish

@drewfish drewfish closed this Nov 28, 2012

Hi @bthaeler,

The develop-perf branch just went away, and github auto-closed pull requests against it. You'll have to redo this pull request against the develop branch. Sorry about this.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment