Re: A question of style, or something more....

Henry wrote:
On Sep 21, 10:16 am, The Natural Philosopher wrote:
teddysn...@xxxxxxxxxxx wrote:
A newbie writes:
Is there any reason to choose one over the other ...
<snip>
Well. It all depends on how good the javascript interpreter
is.

A good optimising C compiler looking at all that would stash what
you have put in 'form' and 'report' in temporary variables anyway.
.so under an optimising compiler the actual code would be identical.

A poor..very poor ..interpreter might use more cycles to execute
the first..so I'd always write it the second way, because I grew
up with assemblers, which don't do anything you don tell them to,
and poor compilers, which didn't even do what you told them to
half the time.

Remember that a C complier only builds an (individual) executable out
of source code once, and then the executable is (potentially) executed
directly many, many times. In this process it doesn't matter how long
the compilation process takes (within reason) so to opportunity to
examine the source code to identify the opportunities for optimization
are unlimited.

Javascript is delivered to its execution environment as source code
text and parsed/complied to something that can be executed prior to
each execution. This means that the time taken compiling will directly
impact on the user's perception of performance. And the number and
nature of optimisations that could be applied will directly impact on
the time taken to compile the code and so on the user's perception of
the performance of the result.

So an important criteria for a "good" javascript complier is that it
be a quick javascript complier.

The dynamic nature of javascript heavily impacts on what would be
required in order to apply optimisations. for example, when you say
that a good "good" compiler would "what you have put in 'form' and
'report' in temporary variables" you are implicitly suggesting that
all executions of - document.getElementById('form_eng') - (for
example) will result in the same code being executed and the same
value being returned. In javascript neither of those things are
necessarily true. The - getElementById - method of the document may
have been replaced with another function, and calls to that new
function may themselves re-replace the document's - getElementsById -
method. And those replacement method may return anything. It is also
the case that script code is imported in separate script elements, and
at different times during the loading of a page.

So for your "good" compiler to know that it was safe to be replacing
the coded action with an optimised alternative it has to examine all
of the javascript in the execution environment in order to be certain
that no actions could happen that would invalidate the optimizations
applied. Which means that for some optimizations it cannot act while
compiling the first script element's contents until it has access to
the code in the last script element (the existence of which it cannot
know about until the HTML parser has seen that element.

Given the need for a javascript compiler to be quick it is unrealistic
to expect it to be applying optimisations that require an examination
of all of the code being loaded into a page, or optimisations that
require a detailed examination of the permutations of possibilities
inherent in the code being loaded.


If you really care. put the two samples inside a loop and iterate
through a few thousand times and time them.

Or just write it the way that would run quickest if no optimisations
where applied (as in this case there is no negative impact on the
readability of the result) and let any quick and easy optimisations
that may be applied in its compilation be a bonus.

Good points.

I had wondered about how much 'look ahead' javsacript interpreters do..
.

Relevant Pages

  • Re: Transfering control without growing control context -- i.e. how to implement GOTO
    ... and arguments to your function calls in javascript. ... resolution prior to the execution. ... The practical result is that you get the optimisations that are cheep ...
    (comp.lang.javascript)
  • Re: A question of style, or something more....
    ... .so under an optimising compiler the actual code would be identical. ... Javascript is delivered to its execution environment as source code ... So an important criteria for a "good" javascript complier is that it ... required in order to apply optimisations. ...
    (comp.lang.javascript)
  • Re: So much for Opteron 32bit compatibility ...
    ... Sun's SPECfp and SPECint performance improvements are entirely ... The optimisations have been extensively discussed ... >> and they are not SPEC specific and are usefull outside the ... performance from a combination of processor design and compiler ...
    (comp.os.vms)
  • Re: Use of TM mechanisms for OoO speculation recovery?
    ... If you take a look at typical code, most such optimisations ... variable accesses by subroutines that limit compiler optimizations? ... My proposed solution to the above was, for my language, ... The routine side effect attributes describe how it accessed any ...
    (comp.arch)
  • Re: C99 is not a failure
    ... Also it is likely to stop the compiler from doing simple optimisations such as strength reduction, so I will have to do a number of optimisations at the C level instead of leaving it up to the optimiser which would re-analyse the code at every build. ... You can't necessarily adapt a commercial package. ... At a minimum tracking down the libraries, make sure they are available for all my platforms of interest etc. ...
    (comp.std.c)