Rajkumar S | 1 Feb 18:12 2004

Re: Measuring Website Performance

An wrote:
> We are developing a "weblication" for our intranet, to cover most of 
> our everyday business issues thru a browser based user interface.

Now I am in a similar position where I have to optimize a web site. Most
of the work is to be done at server side, but I have to make sure that
the page renderings are also quick.

To Start with I am now profiling the current web site. As suggested in
the thread, I am looking at JProf and venkman. Any more tools that will
be interesting for me?

> we are not interested on startup time, but on "loading and rendering"
> time.

Exactly same for me also!

> http://lxr.mozilla.org/mozilla/source/tools/performance/layout/tables/Daily_0324.html
> 
This graph looks pretty neat and ideal for presentations with PHBs, and
shows the pre and post optimization benefits clearly. How was this created?

Thanks for your time,

regrads,

raj
R. Pronk | 3 Feb 14:39 2004
Picon
Picon

Why are Moz-developers so fond of out parameters?

Browsing through the code I was wondering why Moz-developers are so
fond of out parameters. There are so many functions around that return
the value that matters in an out parameter and at the same time return
NS_OK with the normal return statement. Since  many of these functions
return only NS_OK and nothing else it seems a bit of a waste to me so
I wrote a little program to "measure" the "damage" caused by this. I
wrote the following and compiled it under MSVC with optimizations set
for maximum speed. Below every function and statement you can see the
assemblercode it generated.

int func1()
{
	return 33;
}

00401010   mov         eax,21h                 (5 bytes)
00401015   ret                                 (1 byte)

(value returned in eax)
(total 6 bytes)

int func2(int* value)
{
	*value = 64;
	return 9;
}

00401040   mov         eax,dword ptr [esp+4]   (4 bytes)
00401044   mov         dword ptr [eax],40h     (6 bytes)
0040104A   mov         eax,9                   (5 bytes)
(Continue reading)

Boris Zbarsky | 3 Feb 17:42 2004
Picon

Re: Why are Moz-developers so fond of out parameters?

R. Pronk wrote:
> Browsing through the code I was wondering why Moz-developers are so
> fond of out parameters.

They aren't.  Unfortunately, any functions that are actual XPCOM 
interface functions have to use them, since the return value needs to 
indicate the success or failure of the operation.  Since it's an 
interface method, things like "never fails" are actually an 
implementation detail that callers must not know about.

Now there are many methods that _shouldn't_ be interface methods. 
Search for bugs with "decom" in the summary.

And your analysis is spot-on -- removing such bogus COM methods leads to 
codesize and speed wins; see the relevant graphs on tinderbox.  ;)

-Boris
gangadhar npk | 4 Feb 06:10 2004
Picon

Re: Why are Moz-developers so fond of out parameters?

hi,
   As Scott Collins pointed out in the Vol 2 of the brownbag videos, 
there are places where XPCOM is a definite overhead. It is very useful 
in some places (when not be worried about implementations) and in some 
it can be avoided. The [out] parameters that you are talking about is a 
fundamental requirement of the component object model. Any COM (not 
MS-COM, but in general COM) function should return an OK/FAILED for an 
operation. If you look at MS-COM you will see that this helps in case of 
distributed calls.
Since the return value is used, moz-developers are left with no choice 
but to use the [out] parameters.
And your analysis was very crisp. thx
hth
gangadhar

Boris Zbarsky wrote:
> R. Pronk wrote:
> 
>> Browsing through the code I was wondering why Moz-developers are so
>> fond of out parameters.
> 
> 
> They aren't.  Unfortunately, any functions that are actual XPCOM 
> interface functions have to use them, since the return value needs to 
> indicate the success or failure of the operation.  Since it's an 
> interface method, things like "never fails" are actually an 
> implementation detail that callers must not know about.
> 
> Now there are many methods that _shouldn't_ be interface methods. Search 
> for bugs with "decom" in the summary.
(Continue reading)

R. Pronk | 5 Feb 13:13 2004
Picon
Picon

Re: Why are Moz-developers so fond of out parameters?

Thanks. So if I would like to contribute by decomtaminating some part
of Mozilla, is there any way of telling which methods are eligible for
decomtamination? Recently float AppUnitsToDevUnits() and some others
have been decomtaminated in nsIDeviceContext. Does this mean all the
methods in this class can be decomtaminated or are there methods that
should remain the way they are because of frozen interfaces or plugins
that use them? And what e.g. NS_IMETHODIMP
nsCaret::DrawAtPosition(nsIDOMNode* aNode, PRInt32 aOffset)? Many of
the methods in nsCaret.cpp don't result NS_OK, should all methods in
nsCaret be changed that way?

gangadhar npk <gangadharnpk <at> netscapeNOSPAM.net> wrote in message news:<bvpuge$bkc1 <at> ripley.netscape.com>...
> hi,
>    As Scott Collins pointed out in the Vol 2 of the brownbag videos, 
> there are places where XPCOM is a definite overhead. It is very useful 
> in some places (when not be worried about implementations) and in some 
> it can be avoided. The [out] parameters that you are talking about is a 
> fundamental requirement of the component object model. Any COM (not 
> MS-COM, but in general COM) function should return an OK/FAILED for an 
> operation. If you look at MS-COM you will see that this helps in case of 
> distributed calls.
> Since the return value is used, moz-developers are left with no choice 
> but to use the [out] parameters.
> And your analysis was very crisp. thx
> hth
> gangadhar
> 
> Boris Zbarsky wrote:
> > R. Pronk wrote:
> > 
(Continue reading)

Jérôme Lacoste | 5 Feb 13:39 2004
Picon

around 1% page load increase

See the graphes.

http://axolotl.mozilla.org/graph/multiquery.cgi?tboxes=btek%2Cmecca&testname=pageload&points=&autoscale=1&units=&ltype=&avg=1&days=17
http://axolotl.mozilla.org/graph/multiquery.cgi?tboxes=btek%2Cmecca&testname=pageload&points=&autoscale=1&units=&ltype=&avg=1&days=2

I didn't manage to make a better graph URL (e.g. specify the day). Can't 
find doc for graph/rawdata.cgi

According to pike on #mozilla, might be related to those checkins:

http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1075871280&maxdate=1075876019

David, I will let you judge on whether your changes could have created 
this problem. I didn't create a bug in mozilla, and there doesn't appear 
to be one for that specific issue.

Jerome
Jérôme Lacoste | 5 Feb 13:41 2004

around 1% page load increase

See the graphes.

http://axolotl.mozilla.org/graph/multiquery.cgi?tboxes=btek%2Cmecca&testname=pageload&points=&autoscale=1&units=&ltype=&avg=1&days=17
http://axolotl.mozilla.org/graph/multiquery.cgi?tboxes=btek%2Cmecca&testname=pageload&points=&autoscale=1&units=&ltype=&avg=1&days=2

I didn't manage to make a better graph URL (e.g. specify the day). Can't 
find doc for graph/rawdata.cgi

According to pike on #mozilla, might be related to those checkins:

http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=MozillaTinderboxAll&date=explicit&mindate=1075871280&maxdate=1075876019

David, I will let you judge on whether your changes could have created 
this problem. I didn't create a bug in mozilla, and there doesn't appear 
to be one for that specific issue.

Jerome
Jérôme Lacoste | 5 Feb 13:45 2004
Picon

Re: around 1% page load increase

Sorry for the duplicate. Mozilla new appear to have a sort of bug. If 
you cross-post a news-post and copy the issue to somebody by email, if 
your smtp server is not well configured, the news post will go in but 
not the smtp one. Thus retry after fixing the config will duplicate the 
post to the news. Not sure if there's a way to fix that in a simple way.
Boris Zbarsky | 7 Feb 04:56 2004
Picon

Re: Why are Moz-developers so fond of out parameters?

R. Pronk wrote:
> Thanks. So if I would like to contribute by decomtaminating some part
> of Mozilla, is there any way of telling which methods are eligible for
> decomtamination?

You have to have some idea of which interfaces are "public" and which 
aren't (out of the non-IDL ones).

> Recently float AppUnitsToDevUnits() and some others
> have been decomtaminated in nsIDeviceContext. Does this mean all the
> methods in this class can be decomtaminated

Probably, in this case....

> And what e.g. NS_IMETHODIMP
> nsCaret::DrawAtPosition(nsIDOMNode* aNode, PRInt32 aOffset)?

What about it?  It has no out param...

> Many of the methods in nsCaret.cpp don't result NS_OK

Then they need to keep returning nsresult.  ;)

-Boris
gangadhar npk | 9 Feb 10:02 2004
Picon

Are the performance projects still worked on ?

hi all,
   I was going through the performance section of the mozilla projects 
and found that there are few projects for performance improvement 
(http://www.mozilla.org/performance/projects.html). But the last updated 
date seems to be very old. Are these projects still underway or have 
they been shelved ?
thank you
gangadhar

Gmane