SV: [Dynapi-Dev] TCanvas vs. DynLayer

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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.)
2. run-time, the most important.
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.

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.
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).

-----Ursprungligt meddelande-----
Fr=E5n: Pascal Bestebroer <pa...@dy...>
Till: dyn...@li... =
<dyn...@li...>
Datum: den 17 februari 2001 13:44
=C4mne: RE: [Dynapi-Dev] TCanvas vs. DynLayer

>Note that I'm only splitting browser specific code, not complete =
functions
>into seperate files (something I'm strongly against)
>You shouldn't split up source code that is created to make =
split-up-browsers
>to work as one.. doesn't make sense, and will most likely cause =
problems
>when supporting cross-browser code.
>
>What other optimisations are you thinking about?   I've noticed alot of
>email from people saying they have done this, or done that.. but they =
never
>show any code, so please people.. if you did some optimising or other
>ingenious code show us, and don't be so vague
>
>Pascal Bestebroer
>pa...@dy...
>http://www.dynamic-core.net
>
>> -----Oorspronkelijk bericht-----
>> Van: dyn...@li...
>> [mailto:dyn...@li...]Namens Bart Bizon
>> Verzonden: zaterdag 17 februari 2001 13:10
>> Aan: dyn...@li...
>> Onderwerp: SV: [Dynapi-Dev] TCanvas vs. DynLayer
>>
>>
>> Yes... and now we are again getting into the discussion of a
>> split browser API.
>> What you are proposing is taking a step in that direction..
>>  I would take it on step further... and split up the code in
>> different files alltogether (to minimize downloaded code and add =
clarity)
>> ... but let's not dwell upon that... ;)
>> I have been developing my SuperClass for some time now... and
>> recently I have been doing a LOT of optimizing...
>> so I'm getting to be very profitient in this area. And there is
>> room for tons of optimization in DynAPI.
>> But your suggestion is a very good start.
>>
>> >this is not how it should be done. Alot of methods in DynAPI contain =
if
>> >statements for ie/ns checking.. you can optimize this by removing =
the IF
>> >statements from the runtime loop, simple example of setX/setY:
>> >
>> >if (is.ns) {
>> > DynLayer.prototype._setX=3Dfunction(){ this.css.left=3Dthis.x;
>> >this.pageX=3Dthis.getPageX() }
>> > DynLayer.prototype._setY=3Dfunction(){ this.css.top=3Dthis.y;
>> >this.pageY=3Dthis.getPageY() }
>> >} else {
>> > DynLayer.prototype._setX=3Dfunction(){ this.css.pixelLeft=3Dthis.x;
>> >this.pageX=3Dthis.getPageX() }
>> > DynLayer.prototype._setY=3Dfunction(){ this.css.pixelTop=3Dthis.y;
>> >this.pageY=3Dthis.getPageY() }
>> >}
>> >
>> >
>> >Your still assigning methods to the prototype, but at parse time, =
not run
>> >time.. removing the IF statements, and speeding the execution of the =
code
>> >(not by much, but it is an increase in speed)
>> >
>> >This can be done for multiple methods (setHTML, moveTo, setSizez, =
etc)
>> >
>> >
>> >
>> >
>> >
>> >Pascal Bestebroer
>> >pa...@dy...
>> >http://www.dynamic-core.net
>> >
>> >> -----Oorspronkelijk bericht-----
>> >> Van: dyn...@li...
>> >> [mailto:dyn...@li...]Namens Bart Bizon
>> >> Verzonden: vrijdag 16 februari 2001 23:18
>> >> Aan: dyn...@li...
>> >> Onderwerp: SV: [Dynapi-Dev] TCanvas vs. DynLayer
>> >>
>> >>
>> >> true ... but by that definition you would expect windows programs
>> >> to release memory by default... and the OS should handle it .. =
right?
>> >> Which it doesn't.... it's not just DynAPI pages that swallow
>> >> memory, ordinary pages do to...
>> >> and so do many windows programs.
>> >> (But... this is assuming that windows is actually a good OS...
>> >> which it is... NOT)
>> >> Taking this into account... you have to work with the conditions
>> >> at hand...
>> >>
>> >> -----Ursprungligt meddelande-----
>> >> Fr=E5n: Pascal Bestebroer <pa...@dy...>
>> >> Till: dyn...@li...
>> <dyn...@li...>
>> >> Datum: den 16 februari 2001 20:15
>> >> =C4mne: RE: [Dynapi-Dev] TCanvas vs. DynLayer
>> >>
>> >>
>> >> >to be even less helpful here, I truly believe it can't be
>> fixed, and that
>> >> >it's an browser issue..
>> >> >I truly hope I'm wrong, but it seems to me that the javascript
>> >> interpreters
>> >> >should automatically unload any memory no matter what.
>> >> >This is how all (good) environments work) they get space to
>> work in, and
>> >> >once it's done that single memory block is freed.
>> >> >
>> >> >Maybe I'm wrong (and I truly hope so) but I won't be searching =
for a
>> >> >solution on this.
>> >> >
>> >> >Pascal Bestebroer
>> >> >pa...@dy...
>> >> >http://www.dynamic-core.net
>> >> >
>> >> >> -----Oorspronkelijk bericht-----
>> >> >> Van: dyn...@li...
>> >> >> [mailto:dyn...@li...]Namens Michael =
Ellis
>> >> >> Verzonden: vrijdag 16 februari 2001 19:25
>> >> >> Aan: 'dyn...@li...'
>> >> >> Onderwerp: RE: [Dynapi-Dev] TCanvas vs. DynLayer
>> >> >>
>> >> >>
>> >> >> I agree... this is a huge problem. Pretty much makes the
>> >> software unusable
>> >> >> unless you have a ton of ram.
>> >> >>
>> >> >> I currently have a level-3 defect on the memory leak generated =
by
>> >> >> DynAPI for
>> >> >> a software product that is supposed to be out the door in a
>> >> week. We have
>> >> >> not successfully had any impact whatsoever on this issue to =
date.
>> >> >>
>> >> >> Anyone had any luck with this? Anyone have any ideas?
>> >> >>
>> >> >> Mike Ellis
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Lasse Lindg=E5rd [mailto:la...@li...]
>> >> >> Sent: Friday, February 16, 2001 07:00
>> >> >> To: dyn...@li...
>> >> >> Subject: RE: [Dynapi-Dev] TCanvas vs. DynLayer
>> >> >>
>> >> >>
>> >> >> More importantly than upfront performance:
>> >> >> Does it reduce the memory leak ?
>> >> >>
>> >> >> If not then performance will be on a freight train to
>> >> swap-land in no time
>> >> >> anyways.
>> >> >>
>> >> >> My current DynAPI pages eat a meg or more pr. reload. It is
>> not a big
>> >> >> problem at my 256mb machine.  But just the thoughts of my
>> clients 32mb
>> >> >> machines makes me shiver.
>> >> >>
>> >> >> Any news on the memoryleak front ?
>> >> >> Is anybody working on it at all or are everybody busy doing
>> >> "cool" stuff
>> >> >> instead ?
>> >> >>
>> >> >> For DynAPI ever to be useful. We really need to get that
>> memory problem
>> >> >> fixed.
>> >> >>
>> >> >> /Lasse
>> >> >>
>> >> >>
>> >> >> -- __--__--
>> >> >>
>> >> >> Message: 6
>> >> >> From: "Eytan Heidingsfeld" <ey...@tr...>
>> >> >> To: "Dynapi-Dev" <dyn...@li...>
>> >> >> Date: Fri, 16 Feb 2001 14:18:56 +0200
>> >> >> Subject: [Dynapi-Dev] TCanvas vs. DynLayer
>> >> >> Reply-To: dyn...@li...
>> >> >>
>> >> >> This is a multi-part message in MIME format.
>> >> >>
>> >> >> ------=3D_NextPart_000_0002_01C09823.65DE2AF0
>> >> >> Content-Type: text/plain;
>> >> >> charset=3D"iso-8859-1"
>> >> >> Content-Transfer-Encoding: 7bit
>> >> >>
>> >> >> I'd love to test performance one against the other. The only =
test
>> >> >> I did was
>> >> >> create 100 layers and check the times. In IE TCanvas was 200
>> >> ms faster and
>> >> >> in NS it was 1300(canvas) to 10000(dynlayer).
>> >> >>
>> >> >> I'd love you guys to start tearing my canvas to shreds.
>> >> >>
>> >> >> Included in the zip are:
>> >> >> tcanvas.js
>> >> >> browser.js
>> >> >>
>> >> >> they need to be included in the document(working on adding =
.include)
>> >> >>
>> >> >> 8an
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> Dynapi-Dev mailing list
>> >> >> Dyn...@li...
>> >> >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >> >>
>> >> >
>> >> >
>> >> >_______________________________________________
>> >> >Dynapi-Dev mailing list
>> >> >Dyn...@li...
>> >> >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >> >
>> >>
>> >>
>> >> _______________________________________________
>> >> Dynapi-Dev mailing list
>> >> Dyn...@li...
>> >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >>
>> >
>> >
>> >_______________________________________________
>> >Dynapi-Dev mailing list
>> >Dyn...@li...
>> >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >
>>
>>
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>>
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>