headers
Marko Macek | 1 Jan 2008 14:52
Picon

Re: UI latency profiling - bug 15122

Boris Zbarsky wrote:
> Marko Macek wrote:
>> It is necessary to have a debug mozilla build for useful stack traces.
> 
> Why doesn't an optimized build with symbols work?  In general, 
> collecting performance information in a debug build is of rather limited 
> usefulness...

Sorry, I was incorrect. You need a build with debug symbols. That's what I meant.

Mark
Permalink | Reply | 0 comments |
headers
Schrep | 2 Jan 2008 21:51
Picon

Re: moving Mozilla1.8 tinderboxes to Buildbot - perf impact

On Dec 28 2007, 6:43 pm, Robert Helmer <rhel... <at> gmail.com> wrote:
> Cross-posting to m.d.performance this time, as people who care about
> this likely do not watch m.d.builds only.
>
> I've been working on moving the Mozilla1.8 branch tinderboxes to be
> under Buildbot control, by merging nightly builders into the release
> automation projecthttp://wiki.mozilla.org/Build:Release_Automation
>
> You can see the results of the staging machine:http://tinderbox.mozilla.org/Mozilla1.8-Staging/
>
> Currently there are 4 automatically forced builds per day (to keep the
> boxes from falling off of the Tinderbox waterfall, and make sure we
> get a timely nightly), and besides that it only builds on checkin. If
> we can teach Tinderbox server not to drop these builders, then I think
> the ideal would be once forced nightly release and besides that only
> build on checkin.
>
> This is all well and good, but the perf impact I mention in the title
> is that the current build machines build as often as possible, and
> perf machines pick up the results as soon as each build come out.
> Builds generally outrun the perf results, but we get a lot of perf
> runs as a side-effect of the constant build cycles.
>
> I think only building on checkin plus one nightly release is the right
> thing to do, as it reduces cycle time and makes machines available for
> other tasks (releases, verification, etc). However, if we do this then
> the perf boxes will sit idle until a checkin, and we get fewer perf
> runs as a result.
>
> If this is a problem, one idea I had was to just do as many perf runs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Helmer | 3 Jan 2008 11:22
Picon

Re: moving Mozilla1.8 tinderboxes to Buildbot - perf impact

On Jan 2, 12:51 pm, Schrep <mtsch... <at> gmail.com> wrote:
> On Dec 28 2007, 6:43 pm, Robert Helmer <rhel... <at> gmail.com> wrote:
>
>
>
> > Cross-posting to m.d.performance this time, as people who care about
> > this likely do not watch m.d.builds only.
>
> > I've been working on moving the Mozilla1.8 branch tinderboxes to be
> > under Buildbot control, by merging nightly builders into the release
> > automation projecthttp://wiki.mozilla.org/Build:Release_Automation
>
> > You can see the results of the staging machine:http://tinderbox.mozilla.org/Mozilla1.8-Staging/
>
> > Currently there are 4 automatically forced builds per day (to keep the
> > boxes from falling off of the Tinderbox waterfall, and make sure we
> > get a timely nightly), and besides that it only builds on checkin. If
> > we can teach Tinderbox server not to drop these builders, then I think
> > the ideal would be once forced nightly release and besides that only
> > build on checkin.
>
> > This is all well and good, but the perf impact I mention in the title
> > is that the current build machines build as often as possible, and
> > perf machines pick up the results as soon as each build come out.
> > Builds generally outrun the perf results, but we get a lot of perf
> > runs as a side-effect of the constant build cycles.
>
> > I think only building on checkin plus one nightly release is the right
> > thing to do, as it reduces cycle time and makes machines available for
> > other tasks (releases, verification, etc). However, if we do this then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michiel van Leeuwen | 4 Jan 2008 17:16
Picon
Favicon

New tinderbox tests for sunbird/lightning

For the calendar project, there are tinderboxes creating builds. Firefox 
have Ts, Txul and tests like that. But nothing exists for calendar code. 
I'd like to add those somehow. The question is: what would be the best 
way to do that? I don't really know any tinderbox code, but from a first 
look, the test-suite didn't look extedable. The tests are pretty much 
hard coded. Is there some way around that? Is it possible to add new tests?

I'm currently thinking of a testrun that would look like:
sunbird -createprofile perftest
sunbird -P perftest -measurestartup <current time>
sunbird -P perftest -subscribe <url to some ics file>
sunbird -P perftest -measurestartup <current time>
and maybe a few more. The pattern is that I try to make it all 
scriptable from the commandline. But how do I get tinderbox to run that?

Can Talos help in any way?

Michiel
Permalink | Reply | 1 comment |
headers
Boris Zbarsky | 4 Jan 2008 22:07
Picon
Favicon

http://mootools.net/slickspeed/

Would someone be willing to set up a copy of http://mootools.net/slickspeed/ 
that allows an easy way to run individual tests so that they can be profiled 
individually?  That would be very useful for finding and fixing performance 
bottlenecks...

-Boris
Permalink | Reply | 2 comments |
headers
Mike Schroepfer | 16 Jan 2008 04:25

Style animation test - for Tdhtml?

Just saw this

http://www.evilsupergenius.net/frankmaidens.com/dev.php

Shows terribly on FF2 and great on FF3.

Mike
Permalink | Reply | 4 comments |
headers
Boris Zbarsky | 16 Jan 2008 04:52
Picon
Favicon

Re: Style animation test - for Tdhtml?

Mike Schroepfer wrote:
> Just saw this
> 
> http://www.evilsupergenius.net/frankmaidens.com/dev.php
> 
> Shows terribly on FF2 and great on FF3.

Am I missing something?  The page just draws a bunch of stuff once in random 
positions, right?  Or are you clicking "recycle" over and over?

-Boris
Permalink | Reply | 3 comments |
headers
Schrep | 16 Jan 2008 19:33
Picon

Re: Style animation test - for Tdhtml?

On Jan 15, 7:52 pm, Boris Zbarsky <bzbar... <at> mit.edu> wrote:
> Mike Schroepfer wrote:
> > Just saw this
>
> >http://www.evilsupergenius.net/frankmaidens.com/dev.php
>
> > Shows terribly on FF2 and great on FF3.
>
> Am I missing something?  The page just draws a bunch of stuff once in random
> positions, right?  Or are you clicking "recycle" over and over?
>

No not missing anything :-).  Yes - just noticed if you click recycle
to move to random positions the animation is quite jerky on FF2 and
smooth on FF3.   Saw this in the mootools forum for someone asking for
help because the animation looked bad on FF2 but fine on IE, Safari.
Mostly I should have checked out Tdhtml to make sure we are covering
this stuff.  Sorry for the spam - just seeking out situations in the
real world where people are noticing things.
Permalink | Reply | 2 comments |
headers
Boris Zbarsky | 16 Jan 2008 22:17
Picon
Favicon

Re: Style animation test - for Tdhtml?

Schrep wrote:
> No not missing anything :-).  Yes - just noticed if you click recycle
> to move to random positions the animation is quite jerky on FF2 and
> smooth on FF3.

There's an animation?  On trunk when I click "recycle" my CPU pegs for a bit and 
then everything is painted in a new position...

> Mostly I should have checked out Tdhtml to make sure we are covering
> this stuff.

We're not, really.  None of our performance tests cover user perception, 
including animation smoothness.  In fact, quite the opposite: Tdhtml would show 
a win if we had a bug that caused us to stop painting all the intermediate 
frames and only paint the first and last.  Tp has the same problem (e.g. if we 
don't paint or reflow before onload Tp wins, but user perception loses).  Ts and 
Txul may well have similar issues.

If we can figure out a way to quantify and measure DHTML animation smoothness, 
that would be quite nice!

> Sorry for the spam

I don't think it's spam.  It just wasn't clear what the question is.  Thank you 
for explaining!

-Boris
Permalink | Reply | 1 comment |
headers
alice nodelman | 29 Jan 2008 00:28

Re: New tinderbox tests for sunbird/lightning

Talos provides non-tinderbox infrastructure for running those same tests 
(Ts, Tp, Txul, etc).  Talos' follows these basic steps when running any 
given test:

- it creates a clean profile
- runs the browser once to a) ensure that the browser works at all and 
b) to get rid of the first-run overhead
- loads the browser with a given url
- waits for the browser to dump data that is formatted correctly to be 
interpreted as a test result
- waits for the browser to close then cleans up (removes test profile, etc)

It looks to me like a lot of these steps would be the same for calendar. 
  I'm not familiar with the calendar code so I don't know what sort of 
work would be involved in getting Talos to work with it instead of 
browser code, along with redesigning the tests which are all browser 
specific.

There is a doc for setting up your own Talos 
(http://wiki.mozilla.org/StandaloneTalos).  A lot of the information 
wouldn't be applicable, since you don't seem to want to be running the 
actual browser tests - but it will give you a start at understanding the 
Talos code base.

Hope that helps,

alice.

Michiel van Leeuwen wrote:
> For the calendar project, there are tinderboxes creating builds. Firefox
(Continue reading)

Permalink | Reply | 0 comments |

Gmane