This is a META bug for tracking performance issue on multi-core devices. In theory when we have more CPU core we should be able to utilize all the CPUs and improve over all performance. However currently many tasks are still running on main process/main thread only. Some inter-process communications use sync message also effect the CPU utilization. The goal is to identify the issues and make b2g run faster on multi-core devices.

One idea: I think "async" scripts are now parsed in a separate thread; I don't think we use this at all in most apps because the LazyLoader we use set "async = false" to preserve script order.

There's a few things we do when the phone is supposedly idle such as taking an application screenshot or minimizing the memory consumption of background applications. This was explicitly done because on single-core devices those activities would hamper the starting application. We might consider doing these activities immediately if we can prove they don't impact startup time on dual-core devices and up. That would remove some complexity from the codebase and it could save a little power concentrating most of the CPU load in a shorter amount of time at application startup.

2.2 will focus on profiling performance and improving app start-up time. We should consider creating a meta bug to track the specific set of bugs dealing with app start up time and set it's feature flag to 2.2. All other bugs raised as a result of the profiling will be prioritized separately.

(In reply to Adam Rogers (:arog) from comment #4) > 2.2 will focus on profiling performance and improving app start-up time. We > should consider creating a meta bug to track the specific set of bugs > dealing with app start up time and set it's feature flag to 2.2. All other > bugs raised as a result of the profiling will be prioritized separately. I think this makes sense. Can you create the new bug so we can get full commitment from the engineering team?

Hi Thinker, Bobby, and Kevin, After speaking with Adam on this, we need engineering to define the commitments for performance for 2.2. Can you please take the reigns on this so it is very clear what we can commit to (in the next 24 hours?) Thanks!

I am talking with relevant developers for these bugs and some potential problems. Since performance is usually crossing teams, 24 hours seems impossible. By the way, I am trying to check who are assignees.

No only parallel could help to work on multi-core devices. Async also be helpful. Just a clarification.

My current rough plan on this bug is: 1. List things we found are slow 2. Category the slownesses and figure out why 3. Deal with major issues based on the results of (2) 4. Minor improvments afterward I have sent an email to ML dev-b2g and dev-platform to collect more slow things, but so far there's no feedback yet. If you have found any, please help list here. Here're the things I notice while dogfooding Flame: 1. While scrolling in one direction, it pauses for a second if you scroll reversely. 2. It takes some time to show the homescreen when you press home key at card view. 3. Unlock screen does not show homescreen smoothly. 4. Screen does not scroll smoothly with your continuous swipe. 5. Keyboard does not come up right away when you start input. 6. It's janky when you drag at Contacts app to search people by the first character. 7. Press button ">" or "<" to switch forward/backward to screens ususally not happen instantly, this can be seen easily from Settings. 8. Switching between alphabet/symbol keybards is slow. 9. Keyboard seems a bit late than my fingers, you can see the characters come up later if you random press some keys fast and then stop. 10. Dragging web page from Browser app is janky. 11. The animation of moving app out from card view is not smooth 12. Moving icon around while editing homescreen is janky.

I separated application startup time related bugs to bug 1110590.

(In reply to Ting-Yu Chou [:ting] from comment #9) > Here're the things I notice while dogfooding Flame: > ... So we need profiles for each of these cases. (Hopefully profiling all the processes still works since that is very useful. Documentation says "Note: Using ./profile.sh start, without any arguments, will reset the device and start the profiler on all processes once the phone reboots. This mode is deprecated.")

(In reply to Olli Pettay [:smaug] from comment #11) > (In reply to Ting-Yu Chou [:ting] from comment #9) > > Here're the things I notice while dogfooding Flame: > > ... > So we need profiles for each of these cases. Yes, and I hope we can have a more complete list of the slowness, I expect some more cases than what I listed.

(In reply to Olli Pettay [:smaug] from comment #11) > (Hopefully profiling all the processes still works since that is very > useful. Documentation says > "Note: Using ./profile.sh start, without any arguments, will reset the > device and start the profiler on all processes once the phone reboots. This > mode is deprecated.") I just tried, the script still reset the device aand start profiling all the processes. BenWa, what has been deprecated actually?

Only include bug 1110590 in v2.2 feature scope, move overall meta bug in future backlog.

(In reply to Ting-Yu Chou [:ting] from comment #13) > (In reply to Olli Pettay [:smaug] from comment #11) > > (Hopefully profiling all the processes still works since that is very > > useful. Documentation says > > "Note: Using ./profile.sh start, without any arguments, will reset the > > device and start the profiler on all processes once the phone reboots. This > > mode is deprecated.") > > I just tried, the script still reset the device aand start profiling all the > processes. BenWa, what has been deprecated actually? Yes, it's deprecated which means that it's still in the software: http://en.wikipedia.org/wiki/Deprecation

For the record, Thinker told me that he's thinking to move some services out of B2G process main thread, and he prefers doing this from WebIDL by adding new keywords.

I think Bug 709490 could also help. Remove it if you think it is not the case.

[Tracking Requested - why for this release]:

Firefox OS is not being worked on