----- Original Message -----
From: "Bart Bizon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 17, 2001 8:09
AM
Subject: SV: [Dynapi-Dev] TCanvas vs.
DynLayer
It does make sense to split up browser specific
code... the advantages are any...
but that has already been discussed to death... do let's not get into that...
Well, there are so many optimizations that can be done, so it's hard to mention them all at once...
but that's true for almost any large scale project , with a lot of people involved... (many cooks) ;)
Basically , there are two types of optimization that can be done:
1. initialization/creation (this is usually not an issue, before you start initializing/creating a large amount of instances.)
but that has already been discussed to death... do let's not get into that...
Well, there are so many optimizations that can be done, so it's hard to mention them all at once...
but that's true for almost any large scale project , with a lot of people involved... (many cooks) ;)
Basically , there are two types of optimization that can be done:
1. initialization/creation (this is usually not an issue, before you start initializing/creating a large amount of instances.)
Such as say, a tree widget with 200+
nodes?
2. run-time, the most important.
Yes and no.. if it take 30 seconds
for your site to load, then you are likely to lose more than 30-40 % of your
visiters.
If, on the other hand, it takes less than 10 seconds, and the user see's
feedback ("Loading Blah.....") then
It can be hard to loose them.
The problem with optimization is readability. The more optimized the code is , the more unreadable it is.
Though we have to remember that we are dealing with interpreted code, so any optimization is for the better.
Readability is not an issue with proper commenting and
documentation.
2 good points to strive for in both cases:
1. As litte value assignments as possible
Every time you assign anything but a reference, you are in essence copying values. This takes time. A lot more time than conditionals for example.
This is true for just about any programming language
(just confirming yer thought.. :-) )
2. Keeping object references to a minumum.
Goin through an object chain(i.e. obj.reference.value) , takes more time than simply accessing a variable, so try "caching" as much as possible, by storing object chains in temporary variables.
ex.) having DynAPI.prototype.whatever all over the place slows initalization down( and makes code more verbose = bigger in size) ... since the parser has to go through first DynAPI object and then the prototype object each time you assign a property.
>>> var DynProt = DynAPI.prototype ; DynProt.whatever=function(){ etc.... >>> is faster as the parser only has to go through one object reference, DynProt.
This might not be such a big issue initialization wise... but this example is very applicable for run-time code. Especially for IE... since IE is the slower than Netscape at object traversal.. and is worse at GUI rendering ( code must stop executing for the GUI to be updated).
I made this point myself, and was shot down (no names).. certain functions can easily be made 'global' functions..
fer instance to make setHTML global you add a
parameter.. I.E. setHTML(myLayer,"myhtml string"); < ------ no prototype
chain.. no object chain.
---
Outgoing mail is certified Virus Free by AVG Free Edition
http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
