I'd like to make a few meta points related to our tooling: 1. IMO, all tools discussion like this should be cc'd to the tools mailing list. I'd like us to focus tool-specific discussions there: https://lists.mozilla.org/listinfo/tools Currently we have simultaneous tools discussions happening in internal mailing lists, directly between people, dev-b2g, dev-platform, dev-gaia, mozilla.dev.developer-tools, and tools! :)
2. I wrote a similar tool to firewatch that can be found here: http://mzl.la/1k4u6g2 It too polls using adb shell and gathers data over time for memory leak detection. It even outputs .csv for graphing in a spreadsheet and can have it's output piped to a real-time display (PyTk FTW). 3. It's painfully obvious that we have multiple solutions for the same problems. It's also painfully obvious that it isn't easy for developers to find out about existing tools (I know, I've been digging for days) and therefore build their own solution under the false pretense that a tool doesn't already exist. (I'm guilty of this myself, see #2). 4. Polling via adb shell is the least efficient way to gather real-time data. I think we need to settle on a single protocol/transport that gets transmitted over a socket to the host PC. As of right now we have the following solutions: 4.1. The dev-tools/remote-debugging protocol which is used by the App Manager/Developer Tools for debugging a b2g device. See here: http://bit.ly/1k4z8Jq that's pretty awesome. They use the adb helper bridge add-on to drive ADB and set up port forwarding for the socket connections. The remote debugging protocol is documented here: http://mzl.la/1k4Amo8 with discussion/code here: http://bit.ly/1k4AqUJ Notice that the protocol is *JSON*. 4.2. The structured log for test protocol documented here: http://bit.ly/1k4AwvB This is being built into marionette for driving tests and reporting results in realtime. There's a zeromq based transport and consumer being developed here: http://bit.ly/1k4AK64 and http://bit.ly/1k4AW5a respectively. Notice that the protocol is *JSON*. 4.3. The (file-based) profiling data format that is output by the gecko sampling profiler (SPS) http://mzl.la/1k4BPef That data is consumed by Cleopatra http://bit.ly/1k4BW9t The profiler works in both Firefox and FxOS. When profiling the browser, you control the profiler you need the profiler add-on http://bit.ly/1k4C7la There's even a symbols server http://bit.ly/1k4CkVs Notice that the format is *JSON*. 4.4. The fxos powertool http://bit.ly/1k4GexN output format for reporting power consumption numbers. It can output JSON and .csv. :BenWa is integrating the powertool with the sampling profiler so that we can get power consumption graphed in Cleopatra along with profiling data. Notice that the format is *JSON*. This is fast becoming an untenable mess. HOWEVER, all of the above protocols are JSON! This gives us an opportunity to build a unified pub/sub system for reporting data in real-time (serialized in JSON) to a host PC. Everybody is correct in their designs so far. The remote debugging protocol is great for what it does. The structured log for test protocol is perfect for test result reporting. The profiler protocol does exactly what is needed and :BenWa is correct that the sampling profiler (SPS) + cleopatra does a lot more than the simplified profiler in the Firefox dev-tools. We can all stick with our existing protocols. We won't have to throw away the existing work. What I'm proposing is that we just feed all of our data through a unified socket transport with a pub/sub mechanism for "routing". That way we can unify--when it makes sense--existing tools that overlap capability. I think the low-hanging fruit here is to start merging cleopatra into the existing dev-tools profiler as an "advanced mode" for the profiler. We can then add in Harald's (and :bkelly's prototype, and :hub's implemented) real-time memory reporting into the profiler timeline. I'm working on profiler markers from JS (console.addMarker) that can get added in. We're also looking at adding OOM, memory pressure and zRAM events as well. It would also be great to have wake-lock counts, display brightness, GPS state, WiFi state, and anything we can gouge out of the RIL daemon about the baseband radio. How awesome would it be to have all of that reported in one, obvious, place: Tools > Web Developer > Profiler ?!? I want to get all of your feedback on this. I think the correct direction to take in the short term is to focus on the ADB Helper add-on to facilitate setting up the socket forwarding and environment variables on the b2g device for tools to "discover" which IP/port they should connect to for reporting data. I really like the idea of using zeromq as a pub/sub mechanism which allows producers and consumers to join/leave, at will, without disturbing the overall system. But I think alternatives should also be investigated. I'd like any ideas you may have. Once I hear back from all of you, I plan on writing a draft spec that details the ADB Helper add-on and any necessary changes to that. As well as calling out the environment variables that we should use in our tools to discover where to connect for data reporting. I'd also like to setting on a pub/sub mechanism (if needed). I know this may seem sisyphian in nature, but if we all push in the same direction, I think we could end up with an awesome tool! Voltron unite! -dave On 03/25/2014 11:44 AM, Dietrich Ayala wrote: > Harald's tool is a bit different - it's about real-time tracking for > developers. I have an oddly similar tool I wrote for my own use, that > shows real-time graphs of memory and CPU using the same method, to be > able to see the impact of specific sequences of user actions across > multiple processes. > > However, on Tarako I've noticed that it greatly affects the performance > of the device over short periods of time. I haven't looked further into > it - Harald have you seen that issue? > > > ------------------------------------------------------------------------ > > Thanks Harald! > > We (+FxOS Perf Team [1]) have a similar memory tracking effort that > feeds into Datazilla [2]. *Hub*ert Figuiere can speak to its > details. *Ben Kelly* leads our memory performance efforts and *Dave > Huseby* leads our tool development. Please chat with all three about > what you've built and how we can work together on this. > > Mike > > [1]: https://wiki.mozilla.org/B2G/Performance > [2]: http://mzl.la/1giCtEL > > ------------------------------------------------------------------------ > *From: *"Harald Kirschner" <[email protected]> > *To: *"Apps Partner Engineering @ Mozilla" > <[email protected]> > *Cc: *"Dietrich Ayala" <[email protected]>, "Fabrice Desre" > <[email protected]>, "Thomas Elin" <[email protected]>, "Mike Lee" > <[email protected]> > *Sent: *Tuesday, March 25, 2014 11:26:04 AM > *Subject: *Firewatch: Realtime B2G info > > To debug memory use a bit better after hearing that the new dev tool > overlay doesn’t report a good memory indicator here a new approach: > > https://github.com/digitarald/firewatch > > Firewatch is basically a real-time b2g-info, showing only the useful > values (PSS and USS [1]) and free memory. On the roadmap is a > history feature to see max/min/avg/mean values (spikes) and keeping > killed apps. > > I still have to give it a test ride on Tarako and should have more > details later. Feel free to cc more people as feedback is much > appreciated! > > /Harald > > Partner Engineer & Web Craftsman | [email protected] > <mailto:[email protected]> > > [1]: http://elinux.org/Android_Memory_Usage#procrank > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
