Very cool! Definitely something you should bring up on dev-platform, if you haven't already, since it sounds like a pretty big change to gecko.
But it definitely sounds like a really cool idea! / Jonas On Sat, Sep 21, 2013 at 7:05 PM, Thinker K.F. Li <[email protected]> wrote: > It is for all runnables of b2g and content processes. It includes > some changes of IPC to pass information among processes allowing > correlation of runnables of different processes. > > From: Jonas Sicking <[email protected]> > Subject: Re: [b2g] Task tracer > Date: Sat, 21 Sep 2013 11:38:50 -0700 > >> This sounds like something you should post to dev-platform as well. >> >> Are you talking about doing this for just the runnables involved in >> IPC handling, or for *all* implementations runnables posted to >> threads? >> >> One thing to note is that runnables aren't only used for asynchronous >> events. One counterexample is >> >> http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsContentUtils.h?rev=33ec0e812f3b#1485 >> >> so we probably don't need need this for all nsIRunnables, but indeed >> most of them. >> >> / Jonas >> >> On Fri, Aug 23, 2013 at 8:29 AM, Thinker K.F. Li <[email protected]> wrote: >>> Hi all, >>> >>> So many times, I have heard people do not understand why scrolling is so >>> slow, animation is not smooth. Gecko is so async that so many runnables >>> are post over numerous threads, so it is very hard to trace how b2g >>> spend the time for events. Events are timer, input events, network >>> messages. >>> >>> We are working on a tool to help people to correlate runnables spread >>> over threads and processes (b2g & content process). The basic idea is >>> to give every runnable an unique ID, all runnables created by a runnable >>> share the same unique ID. Only the runnables created by events from >>> kernel/platform; e.g. input event, timer, network, sensors, ..., would >>> be assigned a new unique ID. So we can correlate all runnables >>> according unique IDs to understand the tracks of events. >>> >>> The runnables created by events are origins. For example an input event >>> post a runnable on the main thread, that runnable is the origin of the >>> event. The origin gets a new unique ID. The origin may create a series >>> of more runanbles, they all share the same ID. By recording timestamp >>> for equeuing, dequeuing, and completion of runnables, and the unqiue >>> IDs, we can study how b2g spend the time and latency between threads for >>> events. >>> >>> The unique IDs would be passed over IPC, so we can trace runnables >>> passed among processes. Some more information can be attached with the >>> unique IDs. But we would like to start by simple, so I don't mention >>> details here. >>> >>> Cervantes, and others, and I will start to make a prototype. >>> Any feedback is welcomed! >>> >>> -- >>> Sinker >>> -- >>> 天教懶漫帶疏狂 >>> _______________________________________________ >>> dev-b2g mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-b2g >> _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
