Re: Parsing overhead for commenting out line endings

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 49201
interpreted = N
texte = Sorry, Brian. The 'trim' feature does not work quite like you describe. Itwill trim the white space from the left, right, or both sides of the stringas a whole. It does not operate at a line-by-line level.> -----Original Message-----> From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of> Brian Fries> Sent: Friday, April 04, 2003 4:48 PM> To: WebDNA Talk> Subject: Re: Parsing overhead for commenting out line endings>>> Also, see the new Trim parameter for [getchars]... I haven't played> with it yet, but it should allow you to strip returns, tabs> and spaces> at the beginning and end of the enclosed lines of code,> something like> this:>> [replace ...][getchars start=1&end=9999&trim=both]> field1=bob> &field2=mike> &field3=tanya> [/getchars][/replace]>> For pre-v5 systems, I've been using [grep] or [convertchars]> with a db> that strips returns and tabs to serve the same purpose. I used to use> the comment method, but it makes the code hard to read and on complex> pages it definitely had a noticeable performance impact. the> [grep] and> [convertchars] methods are much faster, and hopefully the [getchars> trim=...] will be even better.>> - brian>> On Friday, April 4, 2003, at 03:49 PM, Scott Anderson wrote:>> > The engine creates a new instance of the comment context> for every [!]> > token> > it encounters. So, in the example below, the engine> creates 11 context> > instances (for just one iteration of the loop). Without the extra> > comments,> > the engine would only create 5 context instances. However,> the comment> > context code is fast and small, so the performance hit is not very> > significant. The new [return] context was created to eliminate the> > need to> > use those extra comment blocks when writing a function> definition, as a> > convenience to the programmer. And the code will run a bit faster.> >> >> >> >> -----Original Message-----> >> From: WebDNA Talk> [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of> >> Rob Marquardt> >> Sent: Friday, April 04, 2003 3:08 PM> >> To: WebDNA Talk> >> Subject: Parsing overhead for commenting out line endings> >>> >>> >> I was looking through the 5.0 docs when I found this under> >> the [return]> >> context:> >>> >>> [function name=add_em_up][!]> >>> [/!][text]result=0[/text][!]> >>> [/!][loop start=1&end=10][!]> >>> [/!][text]result=[math][result]+[index][/math][/text][!]> >>> [/!][/loop][!]> >>> [/!][result][!]> >>> [/!][/function]> >>>> >>>> >>> Executing the above function, and wrapping the result with> >> URL tags, we get:> >>> 55> >>>> >>> The extra 'garbage' is gone, but using all those [!][/!]> >> pairs is cumbersome,> >>> and does add some extra parsing overhead.> >>> >> Just how *much* parsing overhead? An appreciable amount? I've> >> been doing> >> this damn near everywhere as a matter of course for years now.> >>> >> [suppressReturns] didn't make it into 5.0? ; )> >>> >>> >> Rob Marquardt> >> Designer/Resident Wirehead> >> Toast Design> >> -- Brian Fries, BrainScan Software --> http://www.brainscansoftware.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/-------------------------------------------------------------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:

Re: Parsing overhead for commenting out line endings (Scott Anderson 2003)
Re: Parsing overhead for commenting out line endings (Brian Fries 2003)
Re: Parsing overhead for commenting out line endings (Scott Anderson 2003)
Parsing overhead for commenting out line endings (Rob Marquardt 2003)

Sorry, Brian. The 'trim' feature does not work quite like you describe. Itwill trim the white space from the left, right, or both sides of the stringas a whole. It does not operate at a line-by-line level.> -----Original Message-----> From: WebDNA Talk [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of> Brian Fries> Sent: Friday, April 04, 2003 4:48 PM> To: WebDNA Talk> Subject: Re: Parsing overhead for commenting out line endings>>> Also, see the new Trim parameter for [getchars]... I haven't played> with it yet, but it should allow you to strip returns, tabs> and spaces> at the beginning and end of the enclosed lines of code,> something like> this:>> [replace ...][getchars start=1&end=9999&trim=both]> field1=bob> &field2=mike> &field3=tanya> [/getchars][/replace]>> For pre-v5 systems, I've been using [grep] or [convertchars]> with a db> that strips returns and tabs to serve the same purpose. I used to use> the comment method, but it makes the code hard to read and on complex> pages it definitely had a noticeable performance impact. the> [grep] and> [convertchars] methods are much faster, and hopefully the [getchars> trim=...] will be even better.>> - brian>> On Friday, April 4, 2003, at 03:49 PM, Scott Anderson wrote:>> > The engine creates a new instance of the comment context> for every [!]> > token> > it encounters. So, in the example below, the engine> creates 11 context> > instances (for just one iteration of the loop). Without the extra> > comments,> > the engine would only create 5 context instances. However,> the comment> > context code is fast and small, so the performance hit is not very> > significant. The new [return] context was created to eliminate the> > need to> > use those extra comment blocks when writing a function> definition, as a> > convenience to the programmer. And the code will run a bit faster.> >> >> >> >> -----Original Message-----> >> From: WebDNA Talk> [mailto:WebDNA-Talk@talk.smithmicro.com]On Behalf Of> >> Rob Marquardt> >> Sent: Friday, April 04, 2003 3:08 PM> >> To: WebDNA Talk> >> Subject: Parsing overhead for commenting out line endings> >>> >>> >> I was looking through the 5.0 docs when I found this under> >> the [return]> >> context:> >>> >>> [function name=add_em_up][!]> >>> [/!][text]result=0[/text][!]> >>> [/!][loop start=1&end=10][!]> >>> [/!][text]result=[math][result]+[index][/math][/text][!]> >>> [/!][/loop][!]> >>> [/!][result][!]> >>> [/!][/function]> >>>> >>>> >>> Executing the above function, and wrapping the result with> >> URL tags, we get:> >>> 55> >>>> >>> The extra 'garbage' is gone, but using all those [!][/!]> >> pairs is cumbersome,> >>> and does add some extra parsing overhead.> >>> >> Just how *much* parsing overhead? An appreciable amount? I've> >> been doing> >> this damn near everywhere as a matter of course for years now.> >>> >> [suppressReturns] didn't make it into 5.0? ; )> >>> >>> >> Rob Marquardt> >> Designer/Resident Wirehead> >> Toast Design> >> -- Brian Fries, BrainScan Software --> http://www.brainscansoftware.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/-------------------------------------------------------------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!

Re: Parsing overhead for commenting out line endings

2003

Top Articles:

Related Readings: