Julie Parent | 1 Sep 01:15 2009

Re: Layout try slaves

Are these running release or dbg?

On Mon, Aug 31, 2009 at 1:12 PM, Marc-Antoine Ruel <maruel <at> chromium.org> wrote:

On Mon, Aug 31, 2009 at 12:39 PM, Brett Wilson<brettw <at> chromium.org> wrote:
> On Mon, Aug 31, 2009 at 10:13 AM, Marc-Antoine Ruel<maruel <at> chromium.org> wrote:
>>
>> If you are not a committer, you can skip this message.
>>
>> If you want to run layout tests as a try job, you can use the layout
>> try slaves. They are not in the default pool so you need to reference
>> them manually.
>>
>> The format is:
>> gcl try foo --bot layout_win,layout_mac,layout_linux
>
> This is great. Is this documented anywhere? Seems like
> http://dev.chromium.org/developers/how-tos/webkit-merge-1 would be a
> very useful place to have it.

I'm not a webkit gardener so I don't think I'm the best person to
modify this page with useful information.

M-A




--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---

Jeremy Moskovich | 1 Sep 01:15 2009

Re: Layout try slaves

Also documented here:

Along with a list of tests currently run by the trybots.

Best regards,
Jeremy

On Mon, Aug 31, 2009 at 1:12 PM, Marc-Antoine Ruel <maruel <at> chromium.org> wrote:

On Mon, Aug 31, 2009 at 12:39 PM, Brett Wilson<brettw <at> chromium.org> wrote:
> On Mon, Aug 31, 2009 at 10:13 AM, Marc-Antoine Ruel<maruel <at> chromium.org> wrote:
>>
>> If you are not a committer, you can skip this message.
>>
>> If you want to run layout tests as a try job, you can use the layout
>> try slaves. They are not in the default pool so you need to reference
>> them manually.
>>
>> The format is:
>> gcl try foo --bot layout_win,layout_mac,layout_linux
>
> This is great. Is this documented anywhere? Seems like
> http://dev.chromium.org/developers/how-tos/webkit-merge-1 would be a
> very useful place to have it.

I'm not a webkit gardener so I don't think I'm the best person to
modify this page with useful information.

M-A




--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---

Marc-Antoine Ruel | 1 Sep 01:47 2009

Re: Layout try slaves


All try slaves are currently in debug.

On Mon, Aug 31, 2009 at 4:15 PM, Julie Parent<jparent <at> chromium.org> wrote:
> Are these running release or dbg?
>
> On Mon, Aug 31, 2009 at 1:12 PM, Marc-Antoine Ruel <maruel <at> chromium.org>
> wrote:
>>
>> On Mon, Aug 31, 2009 at 12:39 PM, Brett Wilson<brettw <at> chromium.org> wrote:
>> > On Mon, Aug 31, 2009 at 10:13 AM, Marc-Antoine Ruel<maruel <at> chromium.org>
>> > wrote:
>> >>
>> >> If you are not a committer, you can skip this message.
>> >>
>> >> If you want to run layout tests as a try job, you can use the layout
>> >> try slaves. They are not in the default pool so you need to reference
>> >> them manually.
>> >>
>> >> The format is:
>> >> gcl try foo --bot layout_win,layout_mac,layout_linux
>> >
>> > This is great. Is this documented anywhere? Seems like
>> > http://dev.chromium.org/developers/how-tos/webkit-merge-1 would be a
>> > very useful place to have it.
>>
>> I'm not a webkit gardener so I don't think I'm the best person to
>> modify this page with useful information.
>>
>> M-A
>>
>> >>
>
>

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

John Grabowski | 1 Sep 01:50 2009

Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)

jam: It's a good idea; we came to the same conclusion.  


I implemented the about:ipc UI as part of our performance focus last week.  However, when I hooked it up, I noticed the logging itself was never fully ported from Windows; it uses a cross-process waitable event, but waitable_event_posix.cc isn't cross-process.  So I'm working on that too.

jrg

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

-~----------~----~----~----~------~----~------~--~---

John Abd-El-Malek | 1 Sep 02:27 2009

Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)



On Mon, Aug 31, 2009 at 4:50 PM, John Grabowski <jrg <at> chromium.org> wrote:
jam: It's a good idea; we came to the same conclusion.  

Good to hear :)  
 
I implemented the about:ipc UI as part of our performance focus last week.  However, when I hooked it up, I noticed the logging itself was never fully ported from Windows; it uses a cross-process waitable event, but waitable_event_posix.cc isn't cross-process.  So I'm working on that too.

It might be easier to make this code work without events, i.e. by sending an IPC message to all child processes when logging state changes.  agl has spent a bit of time looking into this and came to the conclusion that it's too much work (it's the reason that showModalDialog doesn't work on mac/linux btw).  If you can make it work with the same behavior as the Windows event though, that'd be good since it'll make showModalDialog work.


jrg

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

-~----------~----~----~----~------~----~------~--~---

Roland Steiner | 1 Sep 03:11 2009
Picon

Re: Sheriff swap for 9/11-14

Thanks a lot!

If you ever need me to switch in for you, just let me know!

Cheers,

Roland


On Mon, Aug 31, 2009 at 11:49 PM, Mohamed Mansour <m0.interactive <at> gmail.com> wrote:
I could do it, no need to swap. I enjoy sherrifing :)

-- Mohamed Mansour


On Mon, Aug 31, 2009 at 4:17 AM, Roland Steiner <rolandsteiner <at> google.com> wrote:
Hi all,

I'm scheduled for build sheriff duty from 9/11 to 9/14. However, this overlaps our Japanese hackathon, so I wondered if there was a kind sould who would consider swapping sheriff duty with me (preferably with a later date).


Cheers,

Roland





--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---

Jim Roskind | 1 Sep 07:38 2009

Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)

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:
On Mon, Aug 31, 2009 at 9:50 AM, Scott Hess <shess <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

-~----------~----~----~----~------~----~------~--~---

James Su | 1 Sep 12:35 2009

Is it possible to download the binary built by trybot?

Hi,
  I'm currently working on a CL to add some ui tests which are supposed to run without problem on both Linux and Window, but it failed on windows trybot. I'm currently have no Windows machine to build the windows binary. So I'm wondering if there is any way to download the binary built by trybot, so that I can test it in a virtual machine locally?

Regards
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---

Marc-Antoine Ruel | 1 Sep 16:21 2009

Re: Is it possible to download the binary built by trybot?


Short answer: no. Archiving the try job binaries would require storing
a huge amount of (mostly) useless data.

Since you didn't give either the review url or the try job url, I
can't really help. We need an internet equivalent of
http://go/moredata.

Sometimes for really hard to debug problems people simply rdesktop to
a slave. You could also connect to a shared server to try to
reproduce, as you prefer.

Please re-read the try server status email you received.

Thanks,

M-A

On Tue, Sep 1, 2009 at 3:35 AM, James Su<suzhe <at> chromium.org> wrote:
> Hi,
>   I'm currently working on a CL to add some ui tests which are supposed to
> run without problem on both Linux and Window, but it failed on windows
> trybot. I'm currently have no Windows machine to build the windows binary.
> So I'm wondering if there is any way to download the binary built by trybot,
> so that I can test it in a virtual machine locally?
>
> Regards
> >
>

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Paweł Hajdan Jr. | 1 Sep 19:03 2009

please use FlakyTest label and file flakiness bugs

If you disable a flaky test, please file a bug if needed, and assign a FlakyTest label (I'm automatically CC-ed).


This way I can easily search for it. Sometimes a flakiness pattern is more clearly visible then, and it helps. Thanks!

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev <at> googlegroups.com
View archives, change email options, or unsubscribe:
    http://groups.google.com/group/chromium-dev

-~----------~----~----~----~------~----~------~--~---


Gmane