It should be noted that "about:objects" (which currently is really all about
the life-cycle of tasks) is currently only enabled by default in Debug
builds.  If you want to enable it in your personal Release build, add a
line:
#define TRACK_ALL_TASK_OBJECTS

to src/base/tracked.h around line 24 (where it is currently defined iff
building a Debug build).  ...and of course then rebuild, which may take a
while, since it modifies a base class of task.cc.

If you're curious to see lifetimes for tasks that were deleted (a.k.a., were
processed and died) on the UI thread, you could look at:

about:objects/death

That will aggregate info so that all for each thread, all deaths on said
thread are listed together.  For this email-thread, the interesting group to
look at may be the tasks that executed and were destroyed on UI thread.

If you were interested in looking at tasks born on (constructed and posted
from) a specific thread, try:

about:objects/birth

You could then see all tasks posted from the IO thread all together.

You could also look at:

about:objects/birth/death

which would group tasks with common birth AND death thread comonality, and
you might perchance look at the group that were born on the IO, and executed
(and hence died) on the UI thread, or vice versa.

Be warned that timer-tasks can have bogusly long lifetimes... since the time
delay from posting until execution and destruction is listed.  On the
positive side, the exact file/line number is shown for the posting, so you
can look at any suspicious task lifetimes and see if it was a timer-task...
or it was the source of big-time jank!.

I'm OOO this week, or else I'd try to look around and try to see what is
going on... but others may want to play with these facilities.

Hope that helps,

Jim


On Mon, Aug 31, 2009 at 1:58 PM, Eric Roman <[email protected]> wrote:

> On Mon, Aug 31, 2009 at 9:50 AM, Scott Hess <[email protected]> wrote:
> > It might be interesting to have the IO thread tag messages with the
> > time as they go by, and have the UI thread keep track of the
> > distribution of times that messages spend enqueued.  Then we can set
> > goals around how fast IPCs get pulled off the queue.
>
> Our debug builds have this info under:
>
>  about:objects
>
> Which shows how long it took to service tasks posted to the various
> message loops.
> There is also some fancy URL notation to filter the results on that
> page, Jim could tell you more.
>
> On Mon, Aug 31, 2009 at 9:57 AM, John Abd-El-Malek <[email protected]>
> wrote:
> >
> >
> > On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess <[email protected]> wrote:
> >>
> >> On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai<[email protected]>
> wrote:
> >> > Well, that annoying throbber is still chewing up time, causing some
> >> > amount of UI loop contention while the images, thumbnails, and icons
> >> > are fetched.  Windows and Linux don't have a throbber for the new tab
> >> > page.  We shouldn't either.  Excellent, now we're down to 200ms.  It's
> >> > still high, but it's reasonable.  It's a perceptible improvement from
> >> > the 300ms we started with.
> >>
> >> It might be interesting to have the IO thread tag messages with the
> >> time as they go by, and have the UI thread keep track of the
> >> distribution of times that messages spend enqueued.  Then we can set
> >> goals around how fast IPCs get pulled off the queue.
> >
> > The IPC logging code already keeps track of message dispatch time (i.e.
> from
> > when Send() was called until the message handler started executing) and
> > processing time (i.e. how long the handler took).  I don't know how much
> of
> > the UI is implemented on Mac, but on Windows this was only a few hours to
> > implement, and it'll give a lot of insight on which messages are backed
> > up/taking a lot of time.
> >>
> >> -scott
> >>
> >>
> >
> >
> > > >
> >
>

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to