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.)
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.
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).
-----Ursprungligt meddelande-----
Från: Pascal Bestebroer <[EMAIL PROTECTED]>
Till: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Datum: den 17 februari 2001 13:44
Ämne: 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
>[EMAIL PROTECTED]
>http://www.dynamic-core.net
>
>> -----Oorspronkelijk bericht-----
>> Van: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]Namens Bart Bizon
>> Verzonden: zaterdag 17 februari 2001 13:10
>> Aan: [EMAIL PROTECTED]
>> 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=function(){ this.css.left=this.x;
>> >this.pageX=this.getPageX() }
>> > DynLayer.prototype._setY=function(){ this.css.top=this.y;
>> >this.pageY=this.getPageY() }
>> >} else {
>> > DynLayer.prototype._setX=function(){ this.css.pixelLeft=this.x;
>> >this.pageX=this.getPageX() }
>> > DynLayer.prototype._setY=function(){ this.css.pixelTop=this.y;
>> >this.pageY=this.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
>> >[EMAIL PROTECTED]
>> >http://www.dynamic-core.net
>> >
>> >> -----Oorspronkelijk bericht-----
>> >> Van: [EMAIL PROTECTED]
>> >> [mailto:[EMAIL PROTECTED]]Namens Bart Bizon
>> >> Verzonden: vrijdag 16 februari 2001 23:18
>> >> Aan: [EMAIL PROTECTED]
>> >> 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ån: Pascal Bestebroer <[EMAIL PROTECTED]>
>> >> Till: [EMAIL PROTECTED]
>> <[EMAIL PROTECTED]>
>> >> Datum: den 16 februari 2001 20:15
>> >> Ämne: 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
>> >> >[EMAIL PROTECTED]
>> >> >http://www.dynamic-core.net
>> >> >
>> >> >> -----Oorspronkelijk bericht-----
>> >> >> Van: [EMAIL PROTECTED]
>> >> >> [mailto:[EMAIL PROTECTED]]Namens Michael Ellis
>> >> >> Verzonden: vrijdag 16 februari 2001 19:25
>> >> >> Aan: '[EMAIL PROTECTED]'
>> >> >> 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ård [mailto:[EMAIL PROTECTED]]
>> >> >> Sent: Friday, February 16, 2001 07:00
>> >> >> To: [EMAIL PROTECTED]
>> >> >> 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" <[EMAIL PROTECTED]>
>> >> >> To: "Dynapi-Dev" <[EMAIL PROTECTED]>
>> >> >> Date: Fri, 16 Feb 2001 14:18:56 +0200
>> >> >> Subject: [Dynapi-Dev] TCanvas vs. DynLayer
>> >> >> Reply-To: [EMAIL PROTECTED]
>> >> >>
>> >> >> This is a multi-part message in MIME format.
>> >> >>
>> >> >> ------=_NextPart_000_0002_01C09823.65DE2AF0
>> >> >> Content-Type: text/plain;
>> >> >> charset="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
>> >> >> [EMAIL PROTECTED]
>> >> >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >> >>
>> >> >
>> >> >
>> >> >_______________________________________________
>> >> >Dynapi-Dev mailing list
>> >> >[EMAIL PROTECTED]
>> >> >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >> >
>> >>
>> >>
>> >> _______________________________________________
>> >> Dynapi-Dev mailing list
>> >> [EMAIL PROTECTED]
>> >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >>
>> >
>> >
>> >_______________________________________________
>> >Dynapi-Dev mailing list
>> >[EMAIL PROTECTED]
>> >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>> >
>>
>>
>> _______________________________________________
>> Dynapi-Dev mailing list
>> [EMAIL PROTECTED]
>> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>>
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
