Re: [Dynapi-Dev] TCanvas vs. DynLayer

[Doug M. <do...@cr...>]

----- Original Message -----=20
From: "Bart Bizon" <ba...@ho...>
To: <dyn...@li...>
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...=20
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.=20
ex.) having DynAPI.prototype.whatever all over the place slows =
initalization down( and makes code more verbose =3D bigger in size) ... =
since the parser has to go through first DynAPI object and then the =
prototype object each time you assign a property.=20
>>> var DynProt =3D DynAPI.prototype ; DynProt.whatever=3Dfunction(){ =
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