On Jun 25, 2004, at 2:43 AM, Ken Ray wrote:
For a whole bunch of ways to increase performance, check out Wil
Dijkstra's
awesome research into increasing script performance:
There is some good stuff there...
I just went through and removed all of my put i + 1 into i routines.
;-)
--
Troy
On Jun 24, 2004, at 1:49 AM, Brian Yennie wrote:
For example, if I wanted to remove HTML tags from text, I'd probably
use something hand-crafted for speed. If I wanted to verify a valid
URL in a strict standards-compliant sense, I'd probably drop in the
nasty RegEx because I wouldn't trust my
take any input at all. At this point I'm figuring to do this part
later tomorrow or Friday, so cast yer votes! ;-)
Well, here are a few tips for the bucket:
1) Offset() is the fastest call you've got. Try to avoid lineOffset()
or itemOffset() if possible. Contains can also be slower, for some
On Wednesday, June 23, 2004, at 10:39 PM, Troy Rollins wrote:
Thanks Mark. I'll look at this.
And, while I don't doubt this has provided good results, may I ask why
you use it instead of a matchText? You didn't indicate if you had done
some form of speed test, or in fact ever compared the two
Mark-
Thursday, June 24, 2004, 7:03:48 AM, you wrote:
MB You learn something new everyday around here. I didn't know that
MB offset() worked faster in caseSensitive to TRUE mode.
Hindsight is wonderful. It makes sense, now that I think about it. If
caseSensitive were false the engine would have
I took a look through the archives, and didn't see anything definitive
about speed advantages in Rev of using matchText with regEx, compared
to more basic chunking techniques - including contains. I find Rev
is a string handling monster with Transcript alone, but don't know just
what it is
Troy Rollins wrote:
I took a look through the archives, and didn't see anything definitive
about speed advantages in Rev of using matchText with regEx, compared to
more basic chunking techniques - including contains. I find Rev is a
string handling monster with Transcript alone, but don't know
On Wednesday, June 23, 2004, at 06:25 PM, Troy Rollins wrote:
Anyone have a real-world sense of the speed difference? I have a
parsing routine which I put together hastily, knowing that it would
need to be later optimized. I'm edging in on that optimization phase,
and I'm wondering what angle
On Jun 23, 2004, at 9:37 PM, Mark Brownell wrote:
Anyone have a real-world sense of the speed difference? I have a
parsing routine which I put together hastily, knowing that it would
need to be later optimized. I'm edging in on that optimization phase,
and I'm wondering what angle I might want
() function from my last message.
-- put getElement(record, /record, tZap) into theElement
From: Troy Rollins [EMAIL PROTECTED]
Date: Wed Jun 23, 2004 6:50:59 PM US/Pacific
To: How to use Revolution [EMAIL PROTECTED]
Subject: Re: Regex (MatchText) speed
Reply-To: How to use Revolution [EMAIL
On Jun 24, 2004, at 1:08 AM, Mark Brownell wrote:
These two functions work with any text for the start spot and any text
for the end spot.
Thanks Mark. I'll look at this.
And, while I don't doubt this has provided good results, may I ask why
you use it instead of a matchText? You didn't indicate
Troy,
My 2 cents- it totally depends on what kind of RegEx you're ending up
with.
RegEx buys you power for expressing complex rules. A hand crafted
solution will almost always run faster, it's just a matter of whether
you can afford to write new code for every case instead of just
12 matches
Mail list logo
