Weird behavoir while using function aliases

[Daniel Rucareanu]

I have the following script:

function Test(){}
Test.F = function(){}
Test.F.FF = function(){}
Test.F.FF.FFF = function(){}
Test.F.FF.FFF.F FFF = function(){}

//var alias = function(){};
var alias = Test.F.FF.FFF.F FFF;

var date1 = new Date();
for (var index = 0; index < 100000; index++)
Test.F.FF.FFF.F FFF();
//alias();
var date2 = new Date();
print(date2.get Time() - date1.getTime() );
Why is it when I use Test.F.FF.FFF.F FFF() I get around 100ms and when I
get alias() I get around 280ms?
What is going on here? This is something I would have never anticipated
and I think that neither of you as well. Aliases whould work faster
then doing lockups at each iteration, right?
Also if I uncomment this line: var alias = function(){}, from 280ms I
get a drop to 265 ms?

Does anybody now the reason for this? It only happends in Firefox (I
have 1.5.0.6). IE and Opera behaive as they should

[Richard Cornford]

VK wrote:

"Alias is more effective then explicit method call" is some
kind of urban legend to me appealing to one of the most
strong mythologems of programming: "shorter text ===
quicker program"; "alias()" is much shorter than
"f.ff.fff.ffff( )", thusly it just has to be more
effective.

Idiot.

With such linear interpretation it would be also obvious
to expect that f() - f.ff.fff.ffff() -
f.ff.fff.ffff.f .ff.fff.ffff() - ...
have to show twice bigger time difference between each
pair from left to right.

You never let English get it the way of your saying nothing worthwile.

In fact the maximum possible performance is very rarely
the primary target in programming. ...

So having realised for yourself that everything you have posted to this
thread to date was utter rubbish you now what to make out that
differences in execution speed don't matter anyway? You would have been
better off staying silent from the outset as then you could avoid looking
such a fool.

Richard.

[VK]

Richard Cornford wrote:

Idiot.

Halfwit.

With such linear interpretation it would be also obvious
to expect that f() - f.ff.fff.ffff() -
f.ff.fff.ffff.f .ff.fff.ffff() - ...
have to show twice bigger time difference between each
pair from left to right.

You never let English get it the way of your saying nothing worthwile.

I'm sorry if my statement did not fit into your English (neither math)
level. I will try once over step by step:

1) say you have this sequence where each y represents an object
property we want to access and each x some other property we have to
"go throu":
y, x.y, x.x.x.y, x.x.x.x.x.x.x.y , ...

2) in each member of this sequence we have twice longer path to go to
the property y; that is called progression (just in case if you did not
hear this term before). I will not make you all scared by defining what
kind of progression is it (the name starts with "g").

3) With the originally spelled alias idea we must expect that if y has
100ms performance gain over x.y, then x.y over x.x.x.y will give 200ms
gain and so on: we have to expect "twice bigger time difference between
each pair from left to righ".

That is all b.s. at least in application to JScript engine (min.80% of
all users) because its method invocation works on different prociples.

So having realised for yourself that everything you have posted to this
thread to date was utter rubbish you now what to make out that
differences in execution speed don't matter anyway? You would have been
better off staying silent from the outset as then you could avoid looking
such a fool.

Foolish is to discuss internal C++ code mechanics of particular engines
w/o having a clue about this mechanics. That's like writing an esse on
Leo Tolstoy while knowing nothing but that "it's some kind of big
writer".

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>Idiot.

Halfwit.

>>With such linear interpretation it would be also obvious
to expect that f() - f.ff.fff.ffff() -
f.ff.fff.ffff .f.ff.fff.ffff( ) - ...
have to show twice bigger time difference between each
pair from left to right.

You never let English get it the way of your saying nothing
worthwile.

I'm sorry if my statement did not fit into your English
(neither math) level.

It is incoherent.

I will try once over step by step:

1) say you have this sequence where each y represents
an object property we want to access and each x some
other property we have to "go throu":
y, x.y, x.x.x.y, x.x.x.x.x.x.x.y , ...

2) in each member of this sequence we have twice longer
path to go to the property y; that is called progression
(just in case if you did not hear this term before). I
will not make you all scared by defining what kind of
progression is it (the name starts with "g").

3) With the originally spelled alias idea we must expect
that if y has 100ms performance gain over x.y, then x.y
over x.x.x.y will give 200ms gain and so on: we have to
expect "twice bigger time difference between each pair
from left to righ".

That is all b.s. at least in application to JScript engine
(min.80% of all users)

Given that you standards of analysis don't run to distinguishing between
when the code you write works and when it doesn't:-

<URL:
http://groups.google.com/group/comp....20fbcd4b4ab7f8

>

- and you once posted statistics from your own logs that stated that more
of your visitors use Safari than use Mac OS 10 (an impossibility that you
did not notice), I do not place much credence on your declaration of
browser usage. In fact I wouldn't trust you try to addition and get the
answer right.

because its method invocation works on different prociples.

You have just wasted more words saying nothing again. This is a 'straw
man' argument as nobody has ever suggested that the length of a property
accessor would be proportional to the time taken to resolve it. Indeed it
is unlikely that anyone who understands javascript would ever think
anything of the sort as the resolution of a properties on any object may
involve its prototype chain, and so may be influenced by the length of
that chain.

It is not much of an achievement to declare that something that nobody
believes anyway is bullshit.

>So having realised for yourself that everything you have
posted to this thread to date was utter rubbish you now
what to make out that differences in execution speed don't
matter anyway? You would have been better off staying silent
from the outset as then you could avoid looking such a fool.

Foolish is to discuss internal C++ code mechanics of particular
engines w/o having a clue about this mechanics.

<snip>

So why are you doing so? Isn't it more foolish to know that what you are
doing if foolish and then to do it anyway? Indeed isn't it irrational?

Richard.