headers
Jim Nance | 1 May 2003 03:17

Making performance work easier

Hello All,
    I have not done any mozilla work for a while so I decided to do a jprof
run and make one of the functions faster.
    I chose a prominent function from the profile, redesigned the way it
worked, and reimplemented it.  I did another jprof run and found that it
didn't even show up any more.  I created a patch and filed a bugzilla bug
with the patch attached.
    Next the module owner asked me a very reasonable question: How
much faster is your code, does it make a difference?  And I have
no answer.  I know it is somewhat faster because it disappeared from
the jprof profile, but jprof is a very crude profiling tool so that
does not mean much.  I dont have a way to run the page load tests.
I dont have quantify nor a testharness to run it with.
    I think this is a problem.  It is understandable that module owners
want numbers before they churn their code.  But it is bad to discourage
performance contributions from people who can not generate these
numbers.
    Here is what I would like to see to address this problem.  I would
like a way to submit patches to some mozilla.org robot which would
build the code with and without my patches, run performance and regression
tests and send me the results.  My purpose in sending this mail is to
start a discussion about such a robot.  I want to see what others think
of this idea, and see if it is worthwhile to persue this idea.

Thanks,

Jim
Permalink | Reply | 13 comments |
headers
Boris Zbarsky | 1 May 2003 04:34
Picon
Favicon

Re: Making performance work easier

Jim Nance wrote:

>     Here is what I would like to see to address this problem.  I would
> like a way to submit patches to some mozilla.org robot which would
> build the code with and without my patches, run performance and regression
> tests and send me the results.  My purpose in sending this mail is to
> start a discussion about such a robot.  I want to see what others think
> of this idea, and see if it is worthwhile to persue this idea.

I've wished for such a robot on many occasions, if only to run the 
pageload tests....

Of course the standard perf tests that Tinderbox runs are also fairly 
coarse and things can get lost in the noise... but being able to test 
patches against them would be wonderful.

So I think this is definitely worthwhile to pursue, if at all feasible.

-Boris
Permalink | Reply | 12 comments |
headers
Chris Hofmann | 1 May 2003 05:34
Picon

Re: Making performance work easier


Boris Zbarsky wrote:

> Jim Nance wrote:
>
>>     Here is what I would like to see to address this problem.  I would
>> like a way to submit patches to some mozilla.org robot which would
>> build the code with and without my patches, run performance and 
>> regression
>> tests and send me the results.  My purpose in sending this mail is to
>> start a discussion about such a robot.  I want to see what others think
>> of this idea, and see if it is worthwhile to persue this idea.
>
>
> I've wished for such a robot on many occasions, if only to run the 
> pageload tests....
>
> Of course the standard perf tests that Tinderbox runs are also fairly 
> coarse and things can get lost in the noise... but being able to test 
> patches against them would be wonderful.
>
> So I think this is definitely worthwhile to pursue, if at all feasible.
>
> -Boris

These ideas have been kicked around before.  Extra complexity and 
reduced value seems to come into play when a system like this is set up 
as a shared resource....   A queue of incoming requests might grow 
pretty large which frustrates submissions and turn around times (no 
matter how many systems we might be able to cough up).   Then on the
(Continue reading)

Permalink | Reply | 9 comments |
headers
Boris Zbarsky | 1 May 2003 05:54
Picon
Favicon

Re: Making performance work easier

Chris Hofmann wrote:
> all on a local system solves most of the problems that I think your 
> trying to address,

This has one problem.  It means you have to devote your local system 
completely to running the test, shutting down all other apps to reduce 
noise (running something as trivial as a CPU meter will introduce enough 
noise into the pageload tests that the effects of most typical "make 
this a little faster" patches would be lost in it -- last I tried 
running the pageload tests locally, the noise level increased by a 
factor of 5 if I ran a clock applet and a CPU meter at the same time).

If one has a system one can totally dedicate to running the performance 
tests, that's fine.  But in that case there is no need for this 
automation business -- just run the tests on this dedicated system.  The 
directions for running the perf tests are pretty clear and easy to 
follow.  The problem is that most Mozilla developers actually use their 
computers for something, and that something is not primarily Mozilla 
development (except for people who work on Mozilla full-time, maybe). 
This means that running perf tests is either not feasible at all or such 
an incredible inconvenience (requiring days if not weeks of preparation 
to ensure no extraneous processes) that it's just not worth it.

The whole point is that it would be good to have a "clean-room" system 
available as a low-noise environment to run the tests in.

> It also offers a developer more control over the environment for 
> interactive debugging.

Interactive debugging shouldn't be happening during the perf tests
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jim Nance | 2 May 2003 04:11

Re: Making performance work easier

In article <3EB095B0.5030303 <at> netscape.com>, Chris Hofmann wrote:

> These ideas have been kicked around before.

I have suggested it in the past and it didnt go anywhere.  I decided to
kick it around again and hope this time is different :-)

> as a shared resource....   A queue of incoming requests might grow 
> pretty large which frustrates submissions and turn around times

I thought that perhaps the requests could be queued from bugzilla.
This at least ensures that there are bugs associated with the patches
people submit, and it also allows you to tie access control into the
bugzilla permissions.

> If anyone has the time to work on this I'd suggest the approach be to 
> first set up a system that runs locally, and not as a remote robot. 

I assume you mean locally to Netscape.  Thats probably a good idea
but it probably means I cant help very much.  Or perhaps I can.  I
already have an account on stage.mozilla.org so I assume there is
not a huge problem with giving outsiders access to mozilla.org
machines.

> Some script automation that:
> 
> pulls two trees
> auto pick up and applies patches to one tree
> runs builds on both trees,
> runs tests and deposits results
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christopher Seawood | 2 May 2003 05:02

Re: Making performance work easier

Jim Nance wrote:
> In article <3EB095B0.5030303 <at> netscape.com>, Chris Hofmann wrote:

>>If this foundation starts to get widely used and seams valuable to many 
>>we could
>>think about experimenting to build a queuing  and  shared resource 
>>management 
>>system around it as a latter step...
> 
> 
> Let me know when we can start :-)

Hasn't this work already been done as part of John Keiser's tinderbox3 
rewrite?

- cls
Permalink | Reply | 1 comment |
headers
Jim Nance | 2 May 2003 14:03

Re: Making performance work easier

In article <b8smm1$62r2 <at> ripley.netscape.com>, Christopher Seawood wrote:

> Hasn't this work already been done as part of John Keiser's tinderbox3 
> rewrite?

I have not idea.  It would be nice if it was.  Just to be clear we are
talking about testing patches before they go into the tree.

Ill hunt around for more info on tinderbox3.  I am trying to convince the
powers that be at my workplace that we need to run it (for our stuff not
mozilla) and I should know more about it.

Thanks,

Jim
Permalink | Reply | 0 comments |
headers
Beata Koszut | 6 May 2003 11:14
Picon

Applets not interacting

Hi,

I'm using Mozilla 1.0 with Debian 3.0 Woody and with jre131_02.xpi plugin 
package installed. Although applets are running in the browser, they do not 
interact with me. Pressing mouse buttons in the range of an applet gives 
only a beep. The same goes for Java Console Window.

Do you know what can be done about it? Or maybe it's browser version's 
malfunction?

Thanx,

Beata
Permalink | Reply | 0 comments |
headers
WorkingOnWise | 6 May 2003 19:01
Picon
Favicon

Re: CPU resources too high

Lennier <nospam <at> nospam.invalid> wrote in message
news:pan.2003.04.06.01.46.38.420720 <at> TRACKING.invalid...
> On Mon, 31 Mar 2003 13:23:08 -0800, MasterYoshidino wrote:
>
> > Using Mozilla on the other hand shoots this up to 100 while building and
> > immediately slows down my system, preventing any sort of multitasking =(
> > (very important while encoding an avi in AviSynth) when its done
> > downloading (hopefully the page is well done and will not crash mozilla
> > into downloading a flash that can not be loaded etc), it requires too
many
> > resources and lags all other processes
>
> Sounds like your OS is not sufficiently controlling what resources each
> process is allowed to use.
>
> Have you tried upgrading to a better OS such as GNU/Linux?
>
> Lennier
>

Upgrade the OS because of an application?!? That sounds a lot like M$
thinking to me. That's the way to help solve a problem Lennier!
Permalink | Reply | 0 comments |
headers
David Spade | 6 May 2003 19:25
Picon

Re: unsubscribe

On 06/05/2003 14:20, Christian Schneider wrote:
> 

...... Like moths to a flame, or lemmings to a cliff.

The unsubscribe instructions can't be *that* difficult to find, can they?

-=Straxus=-
Permalink | Reply | 0 comments |

Gmane