Menu
▾
▴
dynapi-dev
|
From: Bart B. <ba...@ho...> - 2001-02-16 22:10:01
|
No , this will not speed up things at all...
doing:
Class.prototype.method=3Dfunction(){ }
OR
function method(){ }
Class.prototype.method=3Dmethod
OR
Class.prototype.method=3Dfunction method() { }
is essentially the same speed wise.
What you are doing is assigning a reference to a function in either =
case. Whether it has a name or exists previously or not is unimportant. =
It is still a reference.
(oh.. and I tested this just to be sure... did an avarage of about 10000 =
calls =3D=3D no noticable difference)
-----Ursprungligt meddelande-----
Fr=E5n: Jordi - IlMaestro - Ministral <jmi...@or...>
Till: dyn...@li... =
<dyn...@li...>
Datum: den 16 februari 2001 14:23
=C4mne: Re: [Dynapi-Dev] TCanvas vs. DynLayer
>Speed optimization can always be introduced. In fact, the latest =
precreation
>code that caused some old bugs to reappear and some people to complain =
about the
>API going backwards was introduced in order to speed up layer creation,
>something that was not a problem until people started wanting hundreds, =
even
>thousands of layers onscreen.
>
>I've been tempted to suggest this many times but I didn't want to spawn =
another
>"code split-up" argument. Some critical methods like, say, moveTo or =
setSize
>might speed up by doing.:
>
>if(is.ns) DynLayer.prototype.moveTo =3D function A
>else DynLayer.prototype.moveTo =3D function B
>
>I'll try myself in see what happens
>
>Pascal wrote:
>
>> me again :)
>>
>> I don't think this test is really useable.
>> Your current Tcanvas code misses ALOT of things DynLayer takes care =
of.
>>
>> DynLayer sets sizes, z-index,clipping,bgimages in initialisation (and =
also a
>> few other style properties.. note that setting a style property is =
what
>> slows everything down) I once did some optimization tricks to the =
dynlayer,
>> by removing sizes/clipping etc.. this speeds up things BIG TIME, but =
also
>> brakes useability for a large amount of widgets, and is less =
flexible.
>>
>> DynLayer has code included for fast child-creation.. even though =
there are
>> no child layers in your test, this code is still called (function =
calls).
>> This could be made faster in dynlayer, but for now is more readable =
for
>> developers. Do another test with layers containing a large amount =
child
>> layers.. Dynlayer's precreation will probably be faster.
>>
>> shreded enough? ;)
>>
>> Pascal Bestebroer (pb...@oi...)
>> Software ontwikkelaar
>> Oberon Informatiesystemen b.v.
>> http://www.oibv.com
>>
>> > -----Oorspronkelijk bericht-----
>> > Van: dyn...@li...
>> > [mailto:dyn...@li...]Namens Eytan
>> > Heidingsfeld
>> > Verzonden: vrijdag 16 februari 2001 13:19
>> > Aan: Dynapi-Dev
>> > Onderwerp: [Dynapi-Dev] TCanvas vs. DynLayer
>> >
>> >
>> > 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
>
|
|
From: Bart B. <ba...@ho...> - 2001-02-16 22:19:26
|
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.=20 (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...=20 -----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 > |
|
From: Doug M. <do...@cr...> - 2001-02-16 23:53:53
|
hell.. Win98 uses ram even when it's not doign anything. Just to test it, I de-fragged my ram leaving 97 megs free (and no programs running either) then I whent for my smoke break. When I came back I had 61 megs free.. I did this over night and found that I hav 0.04 megs free come morning.. Just ranting. Doug ----- Original Message ----- From: "Bart Bizon" <ba...@ho...> To: <dyn...@li...> Sent: Friday, February 16, 2001 2:17 PM Subject: 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 <pa...@dy...> Till: dyn...@li... <dyn...@li...> 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 >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ård [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. >> >> ------=_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 >> 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 --- 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 |
|
From: Pascal B. <pa...@dy...> - 2001-02-17 09:22:46
|
I'm not saying the OS should take care of it, I'm saying the parser (or
other compiler) should have taken care of inserting memory-freeing.
Borland compilers make sure that when the program is closed the used memory
is freed (pointers, objects, etc..)
This is something the browser should also do, it's creating a workspace
(dom+javascript model) and it should simply destroy everything in its
contents when closing or reloading a new page (i.e.: a new dom + javascript
space)
And not starting an OS discussion here, but there is NO good OS, they all
have flaws and annoying aspects (much like developers :) so work with what
you like. (damn how I want my C64 back)
In reply to your other mail:
"No , this will not speed up things at all...
doing:
Class.prototype.method=function(){ }
OR
function method(){ }
Class.prototype.method=method
OR
Class.prototype.method=function method() { }"
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
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ån: Pascal Bestebroer <pa...@dy...>
> Till: dyn...@li... <dyn...@li...>
> 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
> >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ård [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.
> >>
> >> ------=_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
> >> 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
>
|
|
From: Michael P. <mp...@ph...> - 2001-02-17 14:44:05
|
but what do you do if all you can do is get your hands on a c128 and are forced
to "go 64"?
I am quite angry with myself that I am even sending this. I spent too much time
playing with my old Vic20 / C64 / C128. btw: do you know which of the 8 colors
was lost when the vic twenty was upgraded to the 16 color C64?
Pascal Bestebroer wrote:
> I'm not saying the OS should take care of it, I'm saying the parser (or
> other compiler) should have taken care of inserting memory-freeing.
> Borland compilers make sure that when the program is closed the used memory
> is freed (pointers, objects, etc..)
>
> This is something the browser should also do, it's creating a workspace
> (dom+javascript model) and it should simply destroy everything in its
> contents when closing or reloading a new page (i.e.: a new dom + javascript
> space)
>
> And not starting an OS discussion here, but there is NO good OS, they all
> have flaws and annoying aspects (much like developers :) so work with what
> you like. (damn how I want my C64 back)
>
> In reply to your other mail:
>
> "No , this will not speed up things at all...
> doing:
>
> Class.prototype.method=function(){ }
> OR
> function method(){ }
> Class.prototype.method=method
> OR
> Class.prototype.method=function method() { }"
>
> 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
> 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ån: Pascal Bestebroer <pa...@dy...>
> > Till: dyn...@li... <dyn...@li...>
> > 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
> > >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ård [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.
> > >>
> > >> ------=_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
> > >> 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
--
Michael Pemberton
mp...@ph...
ICQ: 12107010
|
|
From: Pascal B. <pa...@dy...> - 2001-02-17 14:52:31
|
man I feel sorry for you.. really do :) I actually still play some C64 games now and then (emulated) never seen a C128 upclose, but I dare to say that nothing ever invented was better then the C64... no pentium can even come close to the horse power squeezed into such a tiny machine, running on less then 1 mhz, yet being able to do all graphic tricks of a PC.. even the 16color (hardware limited and palette set) could be fooled into more then 16 colors. and don't even get me started on its musical powers... oh man, memories :) Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Michael Pemberton > Verzonden: zaterdag 17 februari 2001 15:42 > Aan: dyn...@li... > Onderwerp: Re: [Dynapi-Dev] TCanvas vs. DynLayer ( I have no life : ) ) > > > but what do you do if all you can do is get your hands on a c128 > and are forced > to "go 64"? > > I am quite angry with myself that I am even sending this. I > spent too much time > playing with my old Vic20 / C64 / C128. btw: do you know which > of the 8 colors > was lost when the vic twenty was upgraded to the 16 color C64? > > Pascal Bestebroer wrote: > > > I'm not saying the OS should take care of it, I'm saying the parser (or > > other compiler) should have taken care of inserting memory-freeing. > > Borland compilers make sure that when the program is closed the > used memory > > is freed (pointers, objects, etc..) > > > > This is something the browser should also do, it's creating a workspace > > (dom+javascript model) and it should simply destroy everything in its > > contents when closing or reloading a new page (i.e.: a new dom > + javascript > > space) > > > > And not starting an OS discussion here, but there is NO good > OS, they all > > have flaws and annoying aspects (much like developers :) so > work with what > > you like. (damn how I want my C64 back) > > > > In reply to your other mail: > > > > "No , this will not speed up things at all... > > doing: > > > > Class.prototype.method=function(){ } > > OR > > function method(){ } > > Class.prototype.method=method > > OR > > Class.prototype.method=function method() { }" > > > > 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 > > 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ån: Pascal Bestebroer <pa...@dy...> > > > Till: dyn...@li... > <dyn...@li...> > > > 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 > > > >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ård [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. > > > >> > > > >> ------=_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 > > > >> 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 > > -- > Michael Pemberton > mp...@ph... > ICQ: 12107010 > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
|
From: Doug M. <do...@cr...> - 2001-02-17 20:04:49
|
> never seen a C128 upclose, It looked pretty much like a c64, but less 'rounded' more 'angular' > but I dare to say that nothing ever invented was better then the C64... I think the first amiga might challenge that. :-) > of a PC.. even the 16color (hardware limited and palette set) could be > fooled into more then 16 colors. Let's hear it for pallet rotation!!! <g> Doug --- 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 |
|
From: Bart B. <ba...@ho...> - 2001-02-17 12:11:25
|
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
>
|
|
From: Bart B. <ba...@ho...> - 2001-02-17 16:10:58
|
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
>
|
|
From: Eytan H. <ey...@tr...> - 2001-02-17 18:19:42
|
Pascal, added all of the set styles and still same time exactly. 8an |
|
From: Eytan H. <ey...@tr...> - 2001-02-17 18:31:25
|
Did a stress test with nested layers created like this (will send file if you want) create 5 layers in each layer create 5 more repeat. This means that the whole thing creates 3125 layers DynAPI version = 59 seconds and change Canvas version = 28 seconds and change this on a PII 700 with 256 RAM imagine the difference on a P1 or even PII? 8an |
|
From: Eytan H. <ey...@tr...> - 2001-02-17 18:58:06
|
Tried with running 3 times in a row. DynAPI - third time 140000 ms and change Canvas - third time 66000 ms and change 8an |
|
From: Doug M. <do...@cr...> - 2001-02-17 20:13:45
|
please send the file! ----- Original Message ----- From: "Eytan Heidingsfeld" <ey...@tr...> To: <dyn...@li...> Sent: Saturday, February 17, 2001 10:32 AM Subject: RE: [Dynapi-Dev] TCanvas vs. DynLayer > Did a stress test with nested layers created like this (will send file if > you want) > create 5 layers > in each layer create 5 more > repeat. This means that the whole thing creates > 3125 layers > DynAPI version = 59 seconds and change > Canvas version = 28 seconds and change > > this on a PII 700 with 256 RAM imagine the difference on a P1 or even PII? > > 8an > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- 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 |
|
From: Eytan H. <ey...@tr...> - 2001-02-17 20:16:16
|
For the stress tests in DynLayer or with canvas? 8an |
|
From: Doug M. <do...@cr...> - 2001-02-17 20:20:12
|
I'd like to see your canvas.. and your test files, the whole she-bang. Later Doug ----- Original Message ----- From: "Eytan Heidingsfeld" <ey...@tr...> To: <dyn...@li...> Sent: Saturday, February 17, 2001 12:17 PM Subject: RE: [Dynapi-Dev] TCanvas vs. DynLayer > For the stress tests in DynLayer or with canvas? > > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev --- 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 |
|
From: Eytan H. <ey...@tr...> - 2001-02-17 20:24:52
Attachments:
tcanvas.zip
|
Included in the zip yet again tcanvas.js and browser.js and the test for DynLayer and TCanvas with nesting and without called: stress.dynlayer.create nested wtime.htm stress.dynlayer.create wtime.htm stress.canvas.create nested wtime.htm stress.canvas.create wtime.htm 8an |
|
From: Doug M. <do...@cr...> - 2001-02-17 21:17:53
|
Thank you, I'll let y'all know what I find.. ( A little third-party testing never hurt right?) ----- Original Message ----- From: "Eytan Heidingsfeld" <ey...@tr...> To: <dyn...@li...> Sent: Saturday, February 17, 2001 12:25 PM Subject: RE: [Dynapi-Dev] TCanvas vs. DynLayer > Included in the zip yet again > tcanvas.js > and > browser.js > > and the test for DynLayer and TCanvas with nesting and without > called: > stress.dynlayer.create nested wtime.htm > stress.dynlayer.create wtime.htm > stress.canvas.create nested wtime.htm > stress.canvas.create wtime.htm > > 8an --- 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 |
|
From: Doug M. <do...@cr...> - 2001-02-17 20:11:27
|
----- 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
|
|
From: Eytan H. <ey...@tr...> - 2001-02-17 20:15:55
|
What I'm telling you is that you don't need all that. My code makes it so much faster with so little optimization (just passing the create responsibility). 8an |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X