I'm wondering how much the devtools protocol would fit your need? (it is already used for any devtool feature and also partialy used in marionette)
Also can't this be integrated into the existing profiler/cleopatra? Finally, there is various goals around Performance tooling in devtools group: https://wiki.mozilla.org/DevTools/Planning/Performance/Details Rob, What is the status/timeline for Performance tools? Can't we ship a naive timeline tool that connects to a device, and then let all platform experts that are willing to contribute here by putting any usefull probe they can think about? 2014-04-08 18:40 GMT+02:00 William Lachance <wlacha...@mozilla.com>: > [ Bcc'ing auto-tools, in case a-team peoples missed this ] > > Hi Dave, > > This sounds really cool. I suspect that posting this on dev.platform might > yield more comments... personally I only have some minor comments which are > hopefully still useful: > > On 04/07/2014 01:34 PM, Dave Huseby wrote: > > Here is what I'm thinking in rough priority order: >> >> 1. Unify event signaling for all sources of "interesting" events. >> >> Right now we have a bunch of "interesting" perf-related events (e.g. >> checkerboarding, memory pressures, zRAM caching, power consumption >> spikes, slow event handling, etc) that are reported in different ways. >> For instance, Ben Kelly showed us how to spot memory pressure events in >> the log output. We learned that the graphics pipeline knows when >> checkerboarding occurs and could report that. We saw how the powertool >> can see when power consumption spikes and could report it. zRAM caching >> events reported from B2G. RIL, WiFi, GPS, etc all reported from B2G in >> the logs. >> > > So I know there was an effort to add performance counters to marionette > last year, which sounds similar to what you are talking about. I think we > eventually abandoned that effort, for what reason I don't know. CC'ing > mdas, who IIRC was working on it -- hopefully she can clarify. > > The first step I think we should take is figuring out a way to report >> interesting events via a unified mechanism. For events generated on the >> device, I think the Profiler::addMarker is the good way to go. Not only >> would it be a single, central reporting mechanism available from both >> C++ and JS, it would also get those events into the profiling capture >> buffer. The profiling capture mechanism has a small circular buffer for >> storing stack traces and markers. There's no reason we couldn't have a >> thread transmitting event markers back to the host over a socket in >> realtime. >> >> For events generated off of the device (e.g. powertool events, >> eideticker events, orangutan input driver events), they could also be >> reported over a socket to the event consumer. >> > > So for orangutan, the thing that counts the most is when we dispatch the > event to the kernel subsystem to the device, not when we trigger the > program off the device. Would it be possible for external programs like > this to report something to gecko, then gecko would report them over the > socket? I don't want to bikeshed the implementation too much, just curious > about your thoughts here... > > 2. Build a single consumer of the event stream. >> >> Once we get event reporting over a socket, the next step is to build a >> centralized consumer of the events. NodeJS is probably a good choice >> for this tool. It should probably function as a daemon on the host >> machine and be capable of detecting devices and executing adb commands >> to set up the port forwarding automagically. The event consumer will >> listen on a single port--like a web server--and accept multiple incoming >> connections from event sources. >> > > So the way android port-forwarding works, it is currently possible for the > host to connect to a tcp socket on the device easily over usb (this is how > we do marionette), but not the reverse. So I suspect it would be easier for > gecko to emit events over a socket, then have some process on the host hook > into that. > > 3. Build a configurable dispatch mechanism for the event consumer. >> >> The last piece involves building a configurable dispatch mechanism for >> hooking up actions to certain events. The first--and maybe the >> only--action we will want is to gather the profiling data for the last N >> seconds whenever we see an interesting event. >> >> For instance, when I'm optimizing idle power draw, a power spike event >> from the powertool should trigger dumping the profiling data for the >> last N seconds. I'll also want the profiling data when I see a >> transient memory spikes and checkerboarding events, and... >> >> Now that I think about it, grabbing the profiler data in response to a >> marker added from JS would be tremendously helpful for debugging JS >> event ordering and dispatching issues (i.e. the gaia window manager). >> >> Proposal: >> >> To keep this simple enough that it could be implemented quickly, I >> propose a very simple event transmission mechanism. The data on the >> socket will flow in only one direction--from the event source to the >> consumer. Events will contain JSON encoded data: a timestamp with >> sub-ms resolution, a subject string, and a body string. The subject is >> what triggers an action, the body is used for any optional/extended >> data. We'll use TCP. >> > > So the ateam has been working on adding something called "structured > logging" to all our frameworks, which uses a json protocol much like what > you're describing. It would be great if you could use something similar > here, so all the python tools we're creating for reading/parsing structured > logs could be reused here. I believe we also have some existing javascript > helper methods in the tree for creating these types of json messages. > Here's a description of the format we're using: > > http://mozbase.readthedocs.org/en/latest/mozlog_ > structured.html#data-format > > Will > _______________________________________________ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g >
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
