All this talk about optimizing string operations got me thinking:
Wouldn't it be a good idea for some of those plugin developers and
perl/string op experts to get together and put together a plugin package -
maybe incorporating the best of ElfData etc - and put it to RS for them to
license the code ( for a price naturally ) and incorporate it in a new
version of RB - maybe one that tidies up all string stuff in a more uniform
manner. Now I know that Elfdata derive income from such plugins, but my
hunch would be that this forms a minor percentage of their overall income
and they might do better just to sell the stuff to RS for a "lump sum".
This would benefit all us RB developers and avoid us having to go for yet
another 3rd party plugin. A big reason behind this I think a lot of us
prefer to work solely within RB or our OWN plugins - because of the risks
and hassles of incorporating 3rd pty libraries into commercial projects.
On 9/12/06 14:58, "William Squires" <[EMAIL PROTECTED]> wrote:
>
> On Dec 9, 2006, at 2:01 AM, Kem Tekinay wrote:
>
>> After some experimentation, I have found the bottleneck to my code
>> and can
>> now write an RB program that runs *faster* than perl.
>>
>> The problem is, it doesn't do just what I want.
>>
>> Consider this perl code:
>>
>> perl -le 'my $isOdd=1 ; while (<>) { chomp ; if ($isOdd) {print
>> ('\''case
>> '\'' , $_) ; $isOdd=0} else {print("r = \"" , $_ , "\"\n") ;
>> $isOdd=1} }'
>> test.txt > perltest.txt
>>
>> Here is the equivalent RB code:
>>
>> #pragma BackgroundTasks false
>> #pragma BoundsChecking false
>>
>> dim fIn, fOut as FolderItem
>> dim t as Double = microseconds
>>
>> fIn = DesktopFolder.Child( "test.txt" )
>> fOut = DesktopFolder.Child( "output.txt" )
>>
>> dim tIn as TextInputStream = fIn.OpenAsTextFile
>> dim tOut as TextOutputStream = fOut.CreateTextFile
>>
>> dim caseStr as string = "case "
>> dim varStr as string = "r = """
>> dim closingStr as string = """" + chr( 13 )
>>
>> dim line as string
>> dim isOdd as boolean = true
>> do until tIn.EOF
>> line = tIn.ReadLine
>> 'if IsNumeric( line ) then
>> if isOdd then
>> tOut.Write( caseStr )
>> tOut.WriteLine( line )
>> isOdd = false
>> else
>> 'line = line.ReplaceAll( """", """""" )
>> tOut.Write( varStr )
>> tOut.Write( line )
>> tOut.WriteLine( closingStr )
>> isOdd = true
>> end if
>> loop
>>
>> tIn.Close
>> tOut.Close
>>
>> t = microseconds - t
>> t = t / 1000000
>>
>> MsgBox( format( t, "#,0.000" ) + " seconds" )
>>
>> If you look at the commented lines, you will see two of the four
>> differences
>> from my original code.
>>
>> First, I use multiple "Write" statements instead of concatenating a
>> string
>> and writing it once. This alone provided a 7-second speedup.
>>
>> Second, I assigned the static text to variables that get written
>> out to the
>> output file.
>>
>> Third, rather than testing a line to see if it's entirely a number,
>> I use a
>> switch to process every other line.
>>
> How about:
>
> If (Asc(line) >= 48) And (Asc(line) <= 57) Then
>
> ?
>
> This should be very fast, as Asc() is just type converting the
> leftmost character of the passed-in string to an integer (in C, it
> would just typecast a 'char' to 'int'), whereas IsNumeric() has
> performance O(N) as - in the worst case - it has to search all N
> characters of the passed in string just to see that one (the last
> one) isn't numeric.
> This can be improved on even further by caching the value of Asc
> (line) into an Integer, then testing the integer for the range 48..57.
>
>> Fourth, I stopped replacing quotes with double-quotes.
>>
>> What the last two have in common is that they replace RB functions
>> (IsNumeric, ReplaceAll), and that is where the bottleneck is.
>> Without these
>> calls, the RB program is slightly faster than the perl version.
>> With either
>> of these, the RB program slows down, and with both, slows down
>> dramatically.
>>
>> The bottom line: Function calls slow down RB significantly, but,
>> other than
>> the simplest applications, there is no way to avoid them. By
>> definition,
>> until this is "fixed", RB programs will run slower than they can, and
>> probably slower than other, better optimized, languages.
>>
>> ______________________________________________________________________
>> ____
>> Kem Tekinay (212)
>> 201-1465
>> MacTechnologies Consulting Fax (914)
>> 242-7294
>> http://www.mactechnologies.com Pager (917)
>> 491-5546
>>
>> To join the MacTechnologies Consulting mailing list, send an e-
>> mail to:
>> [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Unsubscribe or switch delivery mode:
>> <http://www.realsoftware.com/support/listmanager/>
>>
>> Search the archives of this list here:
>> <http://support.realsoftware.com/listarchives/lists.html>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
