Thanks for the link to the performance devtools planning. The details on JS/HTML5 perf in that doc are missing a bunch of stuff. In terms of app performance on FxOS, there are many other things in the gecko and gonk layer that directly affect execution time. You called out GC, but there are many other lower-level things that slow stuff down.
The fxos perf team is already in the process of exposing the lower-level issues to datazilla (e.g. memory usage, zRAM caching, power usage, graphics jank, graphics layering issues, OOM events, memory pressure events, etc). The graphics team already has a few tools for analyzing jank and layering. They also need to be considered when thinking about unifying the tool set. Ultimately, I would like the dev tools in Firefox to incorporate or replace all of the tools we use now (e.g. powertool, cleopatra, layer. I'd also like to provide remote control over on-device debugging tools like the FPS counter, the over-draw rendering and others. For now though, all we really need is to use the profiler to gather execution data and to stop and dump that data when a transient event happens (e.g. OOM, memory pressure, power spike, jank, etc). We're fighting a bunch of bugs related to transient issues that would be much easier to solve if we had that capability. So that's my short-term focus. -dave On 04/08/2014 11:31 AM, Alexandre poirot wrote: > 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 <[email protected] > <mailto:[email protected]>>: > > [ 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 > > <http://mozbase.readthedocs.org/en/latest/mozlog_structured.html#data-format> > > Will > _________________________________________________ > dev-b2g mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/__listinfo/dev-b2g > <https://lists.mozilla.org/listinfo/dev-b2g> > > > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
