Re: Interesting speed comparison ..

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 54394
interpreted = N
texte = Just a follow up... Having examined the PHP and WebDNA test code, I made the following changes: I modified the WebDNA 'text vars' test to create 2500 instances of the same variable name (keeping the incrementing value), just to eliminate the 'known' performance issue of having a large number of text variables on the page. This was to get a more accurate comparison of the other test cases. For the search test, I changed the WebDNA search to 'eqValuedata', rather than 'raValueData'. I think this is a more accurate comparison to the sql 'VALUE =' query. I adjusted the append values, so that the search would still find a matching record. The 'list words' test did not seem to be a fair comparison as the PHP explode() is different animal from the listwords context. I replaced [listwords] with [countwords]. With those few changes, the test results are much more favorable for WebDNA. For the Database tests, WebDNA performed faster on all items except the 'append' test, for which it was about 40% slower. This is likely due to the fact that the WebDNA engine automatically flushes the database to disk after every append. For the File system tests, WebDNA closely matched, or was slightly faster than PHP. The one exception was the 'Delete 500 folders' test for which WebDNA was about 50% slower, which is odd since the 'Create 500 folders' test was performed faster by WebDNA. Something for me to look at. I look forward to running these tests again, once we have improved the text variables code. These tests were run on my dev machine, Win2000, running our latest WebDNA 5.2 build. -----Original Message----- From: Alain Russell [mailto:alain.russell@blackpepper.co.nz] Sent: Friday, November 21, 2003 12:55 PM To: WebDNA Talk Subject: Re: Interesting speed comparison .. Thanks scott .. makes sense .. As andrew has mentioned this morning the test was initially designed to test on WebDNA install against another .. yesterday I was able to shave 10 ticks off one of the WebDNA tests by changing the syntax slightly .. To be really useful we would need to test real world applications - as a side note our PHP version of our CMS is slower than the WebDNA version .. one of the main reasons we made this test .. This page http://utility.blackpepper.co.nz/webdna_speed/show_speed.html has a v5 comparison at the top of the list .. It's actually quite a bit faster than v4.5.1 .. The other important thing to remember is PHP took 140 more lines of code, which is not a lot unless you are talking about a 300 line page ... Sorry for keeping you up all night Scott .. ;) Alain On 22/11/2003, at 9:04 AM, Scott Anderson wrote: > Having seen this, of course I had to download and install PHP on my dev > machine and run the same tests ;) The php_speed.txt had a couple > syntax > errors, but after a couple quick changes it was running fine. I was > up most > of the night working on this ( thanks, Alain and Andrew ;) ) > > The 'text variables' test is definitely the culprit here. Creating a > large > number of WebDNA text variables early in the template, has a dramatic > effect > on ALL other WebDNA processing for the remainder of the template. > > A few reasons for this: > 1. In most cases, WebDNA does not have a 'qualifier' to denote a text > variable, like the '$' in php. The WebDNA parser has to query all > outer > context objects, asking each if it can identify a particular token. > This > does add more parsing overhead. I say 'in most cases', because you can > access text variables using [text]mytextvar[/text], which will resolve > a bit > quicker, since the wrapping [text] identifies the inner content as a > text > variable. > > 2. The list object, used to store and retrieve text variables, is not > optimized for speed. > > 3. Finally, and perhaps the biggest reason for the performance hit, is > the > order in which the WebDNA parser queries the outer context objects, > when > resolving a token. Many tokens, including context names and tag > names, are > run through the list of known text and math variables, before being > identified as a context name or global WebDNA tag. So if the variable > list > is large, identification of context and tags is slowed down. > > > I think on average, most WebDNA programmers will not create hundreds, > or > thousands, of text variables in one template. So they will not be > impacted > by the issues described above. For those that do, there are a few > WebDNA > 5.x features that can be used to help minimize the parsing overhead. > The > [Scope] context can be used to wrap sections of code that create and > use > several text variables, so that they are destroyed when the scope > closes. A > WebDNA array can be used to store a large number of values. A WebDNA > function can be used to define code blocks that need to generate a > large > number of variables. Function calls are wrapped by an implied scope, > so > that variables created within the function are destroyed when the > function > is finished (unless the variables are created explicitly in the global > name > space or an outer scope). > > > We do plan to address the second and third items, so that performance > is > fast even for very large variable lists. > > > > > > > -----Original Message----- > From: Alain Russell [mailto:alain.russell@blackpepper.co.nz] > Sent: Thursday, November 20, 2003 6:53 PM > To: WebDNA Talk > Subject: Interesting speed comparison .. > > > So Andrew has made a copy of the speed test in PHP .. > Interesting results .. > > http://utility.blackpepper.co.nz/webdna_speed/php_speed.php > http://utility.blackpepper.co.nz/webdna_speed/webdna_speed.html > > This is the same machine - Dual 2G G5, Dual HDD .. > > The source code is available for people that know PHP (You'll need to > create a username/database etc) > http://utility.blackpepper.co.nz/webdna_speed/php_speed.txt > > Any comment from SMSI on why variables/math etc are so much slower ?? > > Running v4.5.1 by the way .. > > Alain > ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: Interesting speed comparison .. ( "Scott Anderson" 2003)
  2. Re: Interesting speed comparison .. ( Bob Minor 2003)
  3. Re: Interesting speed comparison .. ( "Scott Anderson" 2003)
  4. Re: Interesting speed comparison .. ( Jesse Proudman 2003)
  5. Re: Interesting speed comparison .. ( Alain Russell 2003)
  6. Re: Interesting speed comparison .. ( "Scott Anderson" 2003)
  7. Re: Interesting speed comparison .. ( Phillip Bonesteele 2003)
  8. Re: Interesting speed comparison .. ( Marc Kaiwi 2003)
  9. Interesting speed comparison .. ( Alain Russell 2003)
Just a follow up... Having examined the PHP and WebDNA test code, I made the following changes: I modified the WebDNA 'text vars' test to create 2500 instances of the same variable name (keeping the incrementing value), just to eliminate the 'known' performance issue of having a large number of text variables on the page. This was to get a more accurate comparison of the other test cases. For the search test, I changed the WebDNA search to 'eqValuedata', rather than 'raValueData'. I think this is a more accurate comparison to the sql 'VALUE =' query. I adjusted the append values, so that the search would still find a matching record. The 'list words' test did not seem to be a fair comparison as the PHP explode() is different animal from the listwords context. I replaced [listwords] with [countwords]. With those few changes, the test results are much more favorable for WebDNA. For the Database tests, WebDNA performed faster on all items except the 'append' test, for which it was about 40% slower. This is likely due to the fact that the WebDNA engine automatically flushes the database to disk after every append. For the File system tests, WebDNA closely matched, or was slightly faster than PHP. The one exception was the 'Delete 500 folders' test for which WebDNA was about 50% slower, which is odd since the 'Create 500 folders' test was performed faster by WebDNA. Something for me to look at. I look forward to running these tests again, once we have improved the text variables code. These tests were run on my dev machine, Win2000, running our latest WebDNA 5.2 build. -----Original Message----- From: Alain Russell [mailto:alain.russell@blackpepper.co.nz] Sent: Friday, November 21, 2003 12:55 PM To: WebDNA Talk Subject: Re: Interesting speed comparison .. Thanks scott .. makes sense .. As andrew has mentioned this morning the test was initially designed to test on WebDNA install against another .. yesterday I was able to shave 10 ticks off one of the WebDNA tests by changing the syntax slightly .. To be really useful we would need to test real world applications - as a side note our PHP version of our CMS is slower than the WebDNA version .. one of the main reasons we made this test .. This page http://utility.blackpepper.co.nz/webdna_speed/show_speed.html has a v5 comparison at the top of the list .. It's actually quite a bit faster than v4.5.1 .. The other important thing to remember is PHP took 140 more lines of code, which is not a lot unless you are talking about a 300 line page ... Sorry for keeping you up all night Scott .. ;) Alain On 22/11/2003, at 9:04 AM, Scott Anderson wrote: > Having seen this, of course I had to download and install PHP on my dev > machine and run the same tests ;) The php_speed.txt had a couple > syntax > errors, but after a couple quick changes it was running fine. I was > up most > of the night working on this ( thanks, Alain and Andrew ;) ) > > The 'text variables' test is definitely the culprit here. Creating a > large > number of WebDNA text variables early in the template, has a dramatic > effect > on ALL other WebDNA processing for the remainder of the template. > > A few reasons for this: > 1. In most cases, WebDNA does not have a 'qualifier' to denote a text > variable, like the '$' in php. The WebDNA parser has to query all > outer > context objects, asking each if it can identify a particular token. > This > does add more parsing overhead. I say 'in most cases', because you can > access text variables using [text]mytextvar[/text], which will resolve > a bit > quicker, since the wrapping [text] identifies the inner content as a > text > variable. > > 2. The list object, used to store and retrieve text variables, is not > optimized for speed. > > 3. Finally, and perhaps the biggest reason for the performance hit, is > the > order in which the WebDNA parser queries the outer context objects, > when > resolving a token. Many tokens, including context names and tag > names, are > run through the list of known text and math variables, before being > identified as a context name or global WebDNA tag. So if the variable > list > is large, identification of context and tags is slowed down. > > > I think on average, most WebDNA programmers will not create hundreds, > or > thousands, of text variables in one template. So they will not be > impacted > by the issues described above. For those that do, there are a few > WebDNA > 5.x features that can be used to help minimize the parsing overhead. > The > [scope] context can be used to wrap sections of code that create and > use > several text variables, so that they are destroyed when the scope > closes. A > WebDNA array can be used to store a large number of values. A WebDNA > function can be used to define code blocks that need to generate a > large > number of variables. Function calls are wrapped by an implied scope, > so > that variables created within the function are destroyed when the > function > is finished (unless the variables are created explicitly in the global > name > space or an outer scope). > > > We do plan to address the second and third items, so that performance > is > fast even for very large variable lists. > > > > > > > -----Original Message----- > From: Alain Russell [mailto:alain.russell@blackpepper.co.nz] > Sent: Thursday, November 20, 2003 6:53 PM > To: WebDNA Talk > Subject: Interesting speed comparison .. > > > So Andrew has made a copy of the speed test in PHP .. > Interesting results .. > > http://utility.blackpepper.co.nz/webdna_speed/php_speed.php > http://utility.blackpepper.co.nz/webdna_speed/webdna_speed.html > > This is the same machine - Dual 2G G5, Dual HDD .. > > The source code is available for people that know PHP (You'll need to > create a username/database etc) > http://utility.blackpepper.co.nz/webdna_speed/php_speed.txt > > Any comment from SMSI on why variables/math etc are so much slower ?? > > Running v4.5.1 by the way .. > > Alain > ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ "Scott Anderson"

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Some Questions (1997) Windows 2.1b2 Append Bug? (1997) Press Release hit the NewsWire!!! (1997) WCS Newbie question (1997) Migrating to NT (1997) Sendmail problem (2002) MacAuthorize and WebMerchant (1997) Reporting form.. (2001) Separate SSL Server (1997) ampersand (1998) Protecting webdelivery (1997) OS Limitations (1998) Can this be done? (2003) grep question - removing spaces (2005) Webcat no longer supported? (2006) time format (2005) [sendmail] questions... (1997) OT ImageMagick on OS X (2003) Bizarre behavior texta behavior (2004) PCS Frames (1997)