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
<eroman <at> chromium.org> 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 <
jam <at> chromium.org> wrote:
>
>
> On Mon, Aug 31, 2009 at 4:50 PM, Scott Hess <
shess <at> chromium.org> wrote:
>>
>> On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai<
mark <at> chromium.org> 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: chromium-dev <at> googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
RSS Feed