473,417 Members | 1,626 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,417 software developers and data experts.

Performance Question: Variablize or reference direct???


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.
Jul 23 '05 #1
7 2305
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." <re************************@fiprojects.moc> wrote in message
news:Ukpze.189896$El.8450@pd7tw1no...

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.

Jul 23 '05 #2
lallous wrote:
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." <re************************@fiprojects.moc> wrote in message
news:Ukpze.189896$El.8450@pd7tw1no...
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
Jul 23 '05 #3
Jc
Randell D. wrote:
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.

Jul 23 '05 #4
"Randell D." <re************************@fiprojects.moc> writes:

....
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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #5
Lasse Reichstein Nielsen wrote:
"Randell D." <re************************@fiprojects.moc> writes:

....
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
Jul 23 '05 #6
Jc wrote:
Randell D. wrote:
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
Jul 23 '05 #7
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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Jul 23 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Andreas Lauffer | last post by:
I changed from Access97 to AccessXP and I have immense performance problems. Details: - Access XP MDB with Jet 4.0 ( no ADP-Project ) - Linked Tables to SQL-Server 2000 over ODBC I used...
133
by: Gaurav | last post by:
http://www.sys-con.com/story/print.cfm?storyid=45250 Any comments? Thanks Gaurav
10
by: Alex Gerdemann | last post by:
Hello, I have spent a bunch of time converting a Java program I wrote to C++ in order to improve performance, and have found that it is not necessarily faster. Specifically, I'm writing a...
6
by: George McLean | last post by:
Hello, I am trying to isolate some performance issues. The database is DB2 v8.1 running on a Win2000 server with 4 processors and 1gb of RAM. The application is a GIS application that uses...
46
by: dunleav1 | last post by:
I have a process that does inserts that runs 50% slower that Oracle and Mssql. Queries normally take 50% slower than normal. DB2, Oracle, Mssql all are configured on same os, same disk array...
5
by: Remco van Engelen | last post by:
Hello, I have a question regarding the ISO C grammar. The syntax of a direct-declarator reads (section A.2.2, page 413 in my copy; the (R1) is just to 'name' the rule for later reference): ...
5
by: Markus Ernst | last post by:
Hello A class that composes the output of shop-related data gets some info from the main shop class. Now I wonder whether it is faster to store the info in the output class or get it from the...
13
by: atlaste | last post by:
Hi, I'm currently developing an application that uses a lot of computational power, disk access and memory caching (to be more exact: an information retrieval platform). In these kind of...
19
by: mdh | last post by:
Perhaps slightly OT, but related to Declarator form. From A8.5, the declarators have the syntax; declarator: ptr (opt) direct-declarator. At the bottom of the page, it says, amongst...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.