[RFC] SoC idea Add-ons resource tracker
Makarov
This mail is about Google Summer of Code project. It is mainly for
Gerv and Chofmann but i send it to maillist and will appreciate any
comments of community.
I am a student and want to take part in GSoC with Mozilla. I would
like to implement idea "Explore and implement JDK7 InvokeDynamic". But
i have two own ideas and want you to judge their adequacy and benefit
to Mozilla. Please tell if they could be SoC project and advice who
can be a mentor.
=== First Idea "Resource tracker for extensions" (Firefox)
== Synopsis
Many users have a lot of add-ons installed. Someone mange them himself
and others download custom pre-configured builds (bundle packages or
use add-ons collections). But they faced to the same problem.Creators
of bundles contribute time to provide multi-functional version that
have certain level of quality. They choose stable add-ons and make
them fine-grained together. The problem is that if browser
responsiveness drastically slow down then user cannot track which
add-ons are guilty of it. There is lack of user instruments for
troubleshooting. Add-ons (auto)updates add oil to the fire. The user
that had good experience with his 50 add-ons can notice some day that
performance got worse after update (of several add-ons at one time).
The project is to make tool that measure impact of add-on on overall
performance and responsiveness.
== What is unique about the project
Chrome Browser have ability to run tabs and extensions in separate
process. Firefox has made the same for plug-ins (most essential part
of this feature) and is doing it for tabs [Electrolysis]. Running in
separate process make possible to view easily how much CPU and memory
resources extension`s process consume. It is made using OS facilities
and can be shown by Shift-Esc in Chromium. But in fact information is
inaccurate because it is low level, include more details about general
browser image and doesn't take in part overheads that introduce
extension another browser processes. So process separation doesn't
solve the problem.
== Relation to other projects.
Existing tools provide abilities for developers to debug and profile
js code. Although they couldn't be easily used to measure impact of
each add-on on overall performance. Technically existing tools "see"
js functions in scope of pages and xul containers. Profiles [Venkman,
firebug, jsdeobfuscator] can measure time of functions execution
separately or inside container. They were primary created to debug
particular scripts than get overall picture. This project will create
single-place information of the all resources consumed by whole
extension.
Moreover js profiles fail to track time spend by add-ons on
instantiation new XUL objects. Time of execution extension`s js
functions is not all CPU-time paid for add-on. Most add-ons integrates
into GUI and XUL usage must be also measured. There is [XUL Profiler]
that do it for whole window. The same will be done to measure
extension impact on UI.
Many extensions are very inaccurate in terms of memory handling.
[Memory Profiler-Jetpack, Leak Monitor] provide access to raw memory
usage and leaking data. This project will show extension-centric
memory resources. This part is optional.
== The more hacking the more problems
There are two features that cannot be laid aside: user scripts and
user chrome. There are two extremely popular extensions that changed
the way we customize our browsers: Greasemonkey and Stylish.
Greasemonkey scripts can be profiled standalone [9]. This project will
show consuming time for each user script separately (like they are
"sub-extensions" of GM). This part is optional. I do not actually know
how difficult implement style applying time measure. Impact of custom
style definitely can be measured by benchmarking in case user what to
know characteristics of his particular user style. User can record
several actions (like in [Selenium]) and tool will execute them with
and without style. This is also optional.
== Success criteria and project deliverables
Project is divided into several stages. I am not sure that is possible
to implement everything during this summer.
1. At first stage project will be implemented as branched browser.
User will launch special build with switches to get information about
his extensions. The work scheme like it was with [xpctools runtime js
profiler]. After a while user can get information about resources
consumed by particular extension.
This basic work will make possible user to troubleshoot poor-coded (or
coded for outdated FF version) add-ons. This is mandatory part.
2. Second stage is implementation addon or internal chrome location to
view results in table. This is mandatory part.
3. Implement start-stop/reset feature. This is mandatory part.
4. Implement add-on XUL profiling for typical actions: open tab, open
window, show page context menu, show Tools menu. This is optional
part.
5. Tracking add-on memory usage. This is optional part.
6. View add-on memory usage by object type, script file. This is optional part.
7. Measure user script separately. Implement viewing them as
"sub-extensions" of GM. This is optional part.
8. Measure user style impact. This is optional part.
== Benefits to Community
This tool will drop off a lot of irrelevant feedback to core Mozilla
technologies directing it to add-ons developers. That will reduce
superfluous QA efforts and improve project processes.
The project will make utility that is essential like task manager for
OS bring end-users greater experience. Mozilla will gain more loyalty
when users will have tool which clearly separate add-ons slowness from
core Firefox performance.
== Refs
[1] http://www.mozilla.org/projects/venkman/
[2] https://jetpack.mozillalabs.com/
[3] https://wiki.mozilla.org/Electrolysis
[4] https://addons.mozilla.org/en-US/firefox/addon/firebug/
[5] http://www.softwareishard.com/blog/firebug/tracing-console-for-firebug/
[6] https://addons.mozilla.org/en-US/firefox/addon/xul-profiler-by-yoono/
[7] https://addons.mozilla.org/en-US/firefox/addon/memory-profiler/
[8] https://addons.mozilla.org/en-US/firefox/addon/leak-monitor/
[9] https://engtech.wordpress.com/2007/11/13/howto-greasemonkey-profiler-firebug/
[10] http://seleniumhq.org/projects/ide/
[11] http://www.mozilla.org/performance/jsprofiler.html
== PS
Gerv and Chofmann, is it ok to place my proposal to Mozilla wiki and
ask you to help me edit it?
Is there any special rules of Mozilla foundations about GSoC (like
proposal format etc)? I didn`t find any except Application Advice.
This project description is core part of proposal. Pretty long, huh.
Should it be cut?
--
Makarov Dmitry