Performance Question: Variablize or reference direct???

[Randell D.]

Folks,

I have a Javascript performance question that I might have problems
explaining...

In PHP, better performance can be obtained dealing directly with a
variable, as opposed to an element in an array... Thus, if I have a
programming routine that utilises $a[1] several times, it is better to
write the value contained in $a[1] to something else, for example,
$vartmp, and have my routine instead use this for its work... I believe
its easier for the engine as it doesn't have to continually parse the
array for the value.

My question is, would this be the same in javascript... For arrays, and
objects...

Thus, if I have a client page/form called 'testForm', with an input tag
field name called 'firstname', which would be more efficient (in terms
of performance)... Would it be better to continually refer to
document.forms['testForm'].elements['firstname'].value
or
document.testForm.firstname.value
or
write one of the above into a string variable called firstname?

I know it would only be a slight performance advantage, but when one is
working on an intranet based application that could have a heavy
dependancy on javascript routines, and when the only thing I know about
my client is the browser name/version, I'm just trying to dot my Tee's
and cross my Eyes ;-)

All help, via the newsgroup (so all can learn), would be greatly
appreciated,

cheers
Randell D.

 

[lallous]

Hello Randell,

IMHO, it is better to use a temp variable as you described.

I've seen that as a great improvement in high level languages such as C++,
so I suppose the logic would apply here as well.

Regards,
Elias

 

[Randell D.]

Hello Randell,

IMHO, it is better to use a temp variable as you described.

I've seen that as a great improvement in high level languages such as C++,
so I suppose the logic would apply here as well.

Regards,
Elias

Folks,

I have a Javascript performance question that I might have problems
explaining...

In PHP, better performance can be obtained dealing directly with a
variable, as opposed to an element in an array... Thus, if I have a
programming routine that utilises $a[1] several times, it is better to
write the value contained in $a[1] to something else, for example,
$vartmp, and have my routine instead use this for its work... I believe
its easier for the engine as it doesn't have to continually parse the
array for the value.

My question is, would this be the same in javascript... For arrays, and
objects...

Thus, if I have a client page/form called 'testForm', with an input tag
field name called 'firstname', which would be more efficient (in terms of
performance)... Would it be better to continually refer to
document.forms['testForm'].elements['firstname'].value
or
document.testForm.firstname.value
or
write one of the above into a string variable called firstname?

I know it would only be a slight performance advantage, but when one is
working on an intranet based application that could have a heavy
dependancy on javascript routines, and when the only thing I know about my
client is the browser name/version, I'm just trying to dot my Tee's and
cross my Eyes ;-)

All help, via the newsgroup (so all can learn), would be greatly
appreciated,

cheers
Randell D.

Thanks for that!

randelld

 

[Jc]

Folks,

I have a Javascript performance question that I might have problems
explaining...

In PHP, better performance can be obtained dealing directly with a
variable, as opposed to an element in an array... Thus, if I have a
programming routine that utilises $a[1] several times, it is better to
write the value contained in $a[1] to something else, for example,
$vartmp, and have my routine instead use this for its work... I believe
its easier for the engine as it doesn't have to continually parse the
array for the value.

My question is, would this be the same in javascript... For arrays, and
objects...

<snip>

In IE at least, DOM access is much slower (more than 10x) than native
JavaScript code, and so anything you can do to eliminate DOM access
will improve performance. This includes storing object references
rather than accessing DOM objects/methods or accessing DOM properties.

I wouldn't worry about using a temp var to hold a reference to an array
item (or to an object property), you would have to be doing loops on
the order of hundreds of thousands before you would see any difference,
and even then, it wouldn't be much of one. I would worry a lot more
about using a temp var to hold a reference to a DOM object/property.

 

[Lasse Reichstein Nielsen]

....

it is better to write the value contained in $a[1] to something
else, for example, $vartmp, and have my routine instead use this for
its work... ....
My question is, would this be the same in javascript... For arrays,
and objects...

It is, for the same reasons. Doing two lookups takes more time than
doing one, no matter how you slice it.

Whether the difference is relevant is another question entirely,
and one that should also be answered before doing anything.

Would it be better to continually refer to
document.forms['testForm'].elements['firstname'].value
or
document.testForm.firstname.value
or
write one of the above into a string variable called firstname?

It's not a very good example, because you don't need to continually
refer to a form control. If you are doing output, you can't expect
it to show up before the current script ends, and if you are reading
the control, it doesn't change that often. In any case, you will
be inside either an event handler or timeout handler, which doesn't
really count as "continually".

But, let's assume that you are referring to it inside a tight loop.
Then I would do loop invariant code extraction, and move
var lastname = document.forms['testForm'].elements['firstname'];
outside the loop.

I know it would only be a slight performance advantage, but when one
is working on an intranet based application that could have a heavy
dependancy on javascript routines, and when the only thing I know
about my client is the browser name/version, I'm just trying to dot my
Tee's and cross my Eyes ;-)

Don't. As Knuth said "Premature optimization is the root of all evil".

Every time you *change* your code for performance reasons, you are
changing it away from what you would have preferred to write ...
which should be the most direct and readable, and therfore easiest
maintainable, code. Makin maintainance harder should *not* be done
without good reason, so don't do performance "optimization" before
you have identified an actual performance problem.


Exactly the case with forms is something where people often write
horrible code to begin with, and an optimization might actually
make it more readable. Too often I see code like:

if (document.forms['foo'].elements['bar'].value == "") {
document.forms['foo'].elements['bar'].value == "missing value";
return false;
} else {
var result = document.forms['foo'].elements['bar'].value;
}
if (document.forms['foo'].elements['baz'].value == "") {
document.forms['foo'].elements['baz'].value == "missing value";
return false;
} else {
var result2 = document.forms['foo'].elements['baz'].value;
}
....

Here both performance and readability would be increased by having
var elems = document.forms['foo'].elements;
....
(that would be "common subexpression elimination"

But that's just an example where the original code is bad, which I
assume yours isn't

/L

 

[Randell D.]

....

it is better to write the value contained in $a[1] to something
else, for example, $vartmp, and have my routine instead use this for
its work...
....

My question is, would this be the same in javascript... For arrays,
and objects...

It is, for the same reasons. Doing two lookups takes more time than
doing one, no matter how you slice it.

Whether the difference is relevant is another question entirely,
and one that should also be answered before doing anything.

Would it be better to continually refer to
document.forms['testForm'].elements['firstname'].value
or
document.testForm.firstname.value
or
write one of the above into a string variable called firstname?

It's not a very good example, because you don't need to continually
refer to a form control. If you are doing output, you can't expect
it to show up before the current script ends, and if you are reading
the control, it doesn't change that often. In any case, you will
be inside either an event handler or timeout handler, which doesn't
really count as "continually".

But, let's assume that you are referring to it inside a tight loop.
Then I would do loop invariant code extraction, and move
var lastname = document.forms['testForm'].elements['firstname'];
outside the loop.

I know it would only be a slight performance advantage, but when one
is working on an intranet based application that could have a heavy
dependancy on javascript routines, and when the only thing I know
about my client is the browser name/version, I'm just trying to dot my
Tee's and cross my Eyes ;-)

Don't. As Knuth said "Premature optimization is the root of all evil".

Every time you *change* your code for performance reasons, you are
changing it away from what you would have preferred to write ...
which should be the most direct and readable, and therfore easiest
maintainable, code. Makin maintainance harder should *not* be done
without good reason, so don't do performance "optimization" before
you have identified an actual performance problem.


Exactly the case with forms is something where people often write
horrible code to begin with, and an optimization might actually
make it more readable. Too often I see code like:

if (document.forms['foo'].elements['bar'].value == "") {
document.forms['foo'].elements['bar'].value == "missing value";
return false;
} else {
var result = document.forms['foo'].elements['bar'].value;
}
if (document.forms['foo'].elements['baz'].value == "") {
document.forms['foo'].elements['baz'].value == "missing value";
return false;
} else {
var result2 = document.forms['foo'].elements['baz'].value;
}
....

Here both performance and readability would be increased by having
var elems = document.forms['foo'].elements;
....
(that would be "common subexpression elimination"

But that's just an example where the original code is bad, which I
assume yours isn't

/L

Your comments are clear and valid however I comment my code well and if
I make small steps to help overall performance, without confusing the
readability of the code, then I see it as a worthwhile exercise - Or I
suppose, putting it another way, learning to write performance friendly
code from the outset shouldn't give me support problems later (since
I'll be used to my own style of writing, and assigned clear names to any
temporary variables I use).

Thanks for the comments/help,

randelld

 

[Randell D.]

Folks,

I have a Javascript performance question that I might have problems
explaining...

In PHP, better performance can be obtained dealing directly with a
variable, as opposed to an element in an array... Thus, if I have a
programming routine that utilises $a[1] several times, it is better to
write the value contained in $a[1] to something else, for example,
$vartmp, and have my routine instead use this for its work... I believe
its easier for the engine as it doesn't have to continually parse the
array for the value.

My question is, would this be the same in javascript... For arrays, and
objects...

<snip>

In IE at least, DOM access is much slower (more than 10x) than native
JavaScript code, and so anything you can do to eliminate DOM access
will improve performance. This includes storing object references
rather than accessing DOM objects/methods or accessing DOM properties.

I wouldn't worry about using a temp var to hold a reference to an array
item (or to an object property), you would have to be doing loops on
the order of hundreds of thousands before you would see any difference,
and even then, it wouldn't be much of one. I would worry a lot more
about using a temp var to hold a reference to a DOM object/property.

Thanks for seperating arrays from DOMs... I tend to forget just how
different they are 'under the bonnet' and thus disregard the overheadsof
javascript communicating with DOM layer...

I'll keep your ideas/suggestions in mind...

cheers
randelld

 

[Michael Winter]

On 08/07/2005 07:48, Randell D. wrote:

[snip]

Thus, if I have a client page/form called 'testForm', with an input tag
field name called 'firstname', which would be more efficient (in terms
of performance)... Would it be better to continually refer to
document.forms['testForm'].elements['firstname'].value

Long-form notation is better (from a good practice point of view), but
slower. Note that you could write it as:

document.forms.testForm.elements.firstname.value

or
document.testForm.firstname.value

Shorthand notation doesn't offer any significant performance improvement
- only two fewer property accesses. I never use it.

or
write one of the above into a string variable called firstname?

How to best optimise this depends on what you're doing elsewhere in the
code, too. For example, if you're only reading the value of 'firstname'
many times, then it would be sufficient to store that value in a
variable and utilise that. However, if you have to write back to field,
you should probably store a reference to the form control as well.
Similarly, if you're accessing many controls within the form, it could
be worthwhile storing a reference to the elements collection.

[snip]

Mike