[ANN] Democratic Revolution

Mark Brownell gizmotron at earthlink.net
Fri Aug 29 09:36:01 EDT 2003


On Friday, August 29, 2003, at 12:55  AM, Geoff Canyon wrote:

> On Thursday, August 28, 2003, at 10:52  PM, Mark Brownell wrote:
>
>> This Xtra was coded using C or C++ to add speed to string searches. 
>> It has a feature findAll() and creates an array in half the time as 
>> the transcript loop.
>
> Just want to make sure I'm reading this right: you're saying that the 
> native C routine is only twice as fast as the equivalent transcript 
> routine?
>
> regards,
>
> Geoff Canyon

Yes. I might be able to speed the transcript parallel numerical array 
builder by converting it to a single loop process. The only reason I 
used the three loop system was that the textCruncher Xtra created the 
char location arrays in the first place. Director was very slow, in 
fact so slow that it wasn't practical. My tests using this PNLP 
technique show that it is just slightly faster than perl regEx in a 
head to head task in transcript. Like I said I think I can speed it up 
some. Here is another thing to consider. I tested the textCruncher Xtra 
  on Mac 9.2 classic on my Mac 10; 900 MHz iBook. That means that the 
speed in classic mode was about 266 MHZ.

If I were to get what I'm really looking for it would be:

getPNLPelements(startTag, endTag, stringToSearch) used like this to get 
an array of elements from a structured document like XML:

put "<record" into tStartT
put "</record>" into tEndT
put getPNLPelements(tStartT, tEndT, stringToSearch) into myArray

used like this:
put myArray[1]
-- transactionNumber="1234567" firstname="Bob" lastname="Smith">item# 
abc123

where:
<record transactionNumber="1234567" firstname="Bob" 
lastname="Smith">item# abc123</record>
were used as the first instance.

If I had a fast native transcript capability that extracted the element 
information between a start tag and an end tag and placed all found 
instances in an array and did this faster than a transcript loop then I 
would really have what I wanted. I would settle for offsetAll() while 
waiting for any speed enhancement in the future. I once referred to 
this process as a pull parser.

Best regards,

Mark Brownell




More information about the use-livecode mailing list