756379 - Performance / Memory profiling

Status: RESOLVED DUPLICATE of bug 797189

(Firefox OS Graveyard :: General, defect)

Description

[Kai-Chih Hu [:khu]]

Memory profiling to see how much we're using on a default build of B2G.

Comment 1

[Kai-Chih Hu [:khu]]

Information from cjones: 

The best place to start here is defining our "use cases", or maybe "user script" would be a better term.  For this, we can grab the old MWC demo script and start expanding it out for new apps and capabilities.

MWC script: https://docs.google.com/document/d/1I59BsiwFNCpHWifdLjQ-uRHqd0eLM0QsL8gXJbMFIXI/edit

When running the user script, the things we want to measure are
 - responsiveness.  How fast something in the UI changes in response to input events (touch, button presses).  Everything should be under 50ms, and an alarm should go off if a response exceeds 100ms.
 - app loading.  (Note: not the same thing as responsiveness.)  How long does it take for apps to fully load after their icons are tapped on the homescreen.  clee has a spreadsheet with some fairly arbitrarily-chosen times from partners. We should be shooting for 100s of milliseconds here.
 - framerate of animations.  Everything has to be 60fps.  Alarms should go off if anything drops below 30fps.
 - "retaining" of background apps.  Ideally, we would keep every app loaded forever, so "load" time is instantaneous.  We'll need to make tradeoffs here when we're running in <=256MB though.  Ideally we wouldn't need to measure this independently, we would fold it into the other categories.  (For example, better retention would lead to shorter startup times.)

Once we have this kind of script in place, we can run through it a *second* (or more) time to ensure we're not over-tuning to a fairly uncommon case (cold startup of everything).  Ideally, the metrics above would only *improve* during a second run.

After this, we can do a battery-life test that just loops through the script until the phone dies.  We want to maximize the amount of time here without affecting the other measurements.

We should be able to automate all of this, but initially we'll need manual runs.  We have all the necessary basic tools, we just need to hook them all up.

Microbenchmarks like "peak memory usage in X" or "peak/average CPU usage of Y" are mostly a waste of time, they don't measure what users see.  Partners request them though.  Ideally, we would use 100% of RAM all the time.  We can pull these together on demand.

We need API that allows us to write a "system monitor"-like application.  We've discussed this in the past but no one is working on it right now.

Comment 2

[Dietrich Ayala (:dietrich)]

Assigning to Justin for now (redirect if needed). Blocking minus for meta-bug. File any actual memory problems and block this bug with them.

Comment 3

[Justin Lebar (not reading bugmail)]

We aren't using this bug anymore.  We're using bug 797189 instead.