_StringReverse - improved approach?

[guinness]

Why not using a plain wstrrev blindly instead?

It has the exact same drawback that every solution shown here so far and will work much faster in probably almost all cases (maybe empty and 1-codepoint strings).

See the quote by trancexx.

[BrewManNH]

The code posted with the timers has a couple of points that aren't taken into account. Here's a rewrite of it that should more accurately tell you how the times are affected.

expandcollapse popup

#include <String.au3>

Local $hTimer = 0
Global $sString = ""
For $I = 1 To 1000
     $sString &= Chr(Random(65, 90, 1))
Next
$hTimer = TimerInit()
Local $aString = StringSplit($sString, '', 2) ; this should be inside the timer function, because strings aren't usually inside an array
For $i = 1 To 100
    StringReverseChrArray($aString) ; Average: 3.67800446704819
Next
ConsoleWrite((TimerDiff($hTimer) / 100) & @CRLF)

$hTimer = TimerInit()
For $i = 1 To 100
    StringReverse($sString) ; Average: 3.06620953221708
Next
ConsoleWrite((TimerDiff($hTimer) / 100) & @CRLF)

$hTimer = TimerInit()
For $i = 1 To 100
    _StringReverse($sString) ; Average: 0.0783702956660693 
Next
ConsoleWrite((TimerDiff($hTimer) / 100) & @CRLF)

Func StringReverseChrArray(ByRef $aString) ; Converted from this: http://marc.info/?l=php-general&m=120422082915762
    Local $sChr = '', $sReturn = ''
    Local $i = 0, $j = UBound($aString) - 1

    While ($i < $j)
        $sChr = $aString[$i]
        $aString[$i] = $aString[$j]
        $aString[$j] = $sChr
        $i += 1
        $j -= 1
    WEnd
EndFunc   ;==>StringReverseChrArray

Func StringReverse($sString)
    Local $sReturn = ''
    For $i = StringLen($sString) To 1 Step -1
        $sReturn &= StringMid($sString, $i, 1)
    Next
    Return $sReturn
EndFunc   ;==>StringReverse

I had to limit it to 100 iterations of the loops because the first test took forever to finish for 100000 loops.

[czardas]

Reversing large strings is pretty standard, so any new method has to accomodate this fact. The tests clearly illustrate the speed problems.

Edited February 3, 2013 by czardas

[guinness]

Apart from the random string, I still believe the StringSplit should be outside of the timer, as this was to mimic the same style as the character array you have in the php example.

Edit: These are the discussions I enjoy most.

Edited February 3, 2013 by guinness

[BrewManNH]

I disagree, if you have a string you need to reverse, and it's not in an array, one character per element, you're going to have to split the string into an array first. Not timing that part of the function negates the value of any timing you do on it. Even without that inside the timer you'll see the difference is negligible in the overall test as it's only split once per loop.

[czardas]

This is about reversing a string. Surely any conversion should be within the function to get a fair test of reversing string methods.

[guinness]

OK, we're looking at the purposes of these 'tests' as totally different. If AutoIt didn't use 'string literals' then it would be a different discussion.

I created the chrarray version to demonstrate if AutoIt was to use character arrays than string literals.

Edited February 3, 2013 by guinness

[czardas]

From my perspective the bottom line is this: creating a more sluggish string reverse function would really complicate a lot of my projects.

[BrewManNH]

Either way, array created in the timer or outside, the difference isn't all that great. It's still slow no matter how you time the reverse function.

[jchd]

MSDN has become a complete mess when it comes to find any doc on primitives actually available not encapsulated behind the layers they want to promote.

I give up.

But the truth is that there must be a way to find "something" inside a "standard" (whatever that means) Windows system able to perform what wcsrev did without breaking the Law.

The point remains that reversing a string is hard work, really hard! No solution so far works in all cases and I'm sure no workable way can be done with AutoIt alone without having to invoke at least two Unicode string functions built into Windows. It would be weird to have to link18 Mib of ICU just for that.

[guinness]

I'm more interested in the "right/correct" approach, speed is always secondary to me. Sorry.

MSDN has become a complete mess when it comes to find any doc on primitives actually available not encapsulated behind the layers they want to promote.

I give up.

I couldn't find any native API call either. I think this is what trancexx was hinting at. Edited February 3, 2013 by guinness

[jchd]

Do you mean that Windows doesn't carry any Unicode string primitive openly available to application development outside .Net, C#, COM+ and their other toys?

If it's not so, then that means the function has to become part of the core so that the relevant primitives/methods can be invoked properly.

If really that's impossible I don't see much future to Windows: way too many programs will stop working at the moment such functions effectively disappear.

[czardas]

I'm more interested in the "right/correct" approach, speed is always secondary to me. Sorry.

The right/correct approach depends on main priorities, and if one of these happens to be speed, then the correct approach is dictatated by the fact. There's no way to circumvent that. Sorry!

Edited February 3, 2013 by czardas

[guinness]

Do you mean that Windows doesn't carry any Unicode string primitive openly available to application development outside .Net, C#, COM+ and their other toys?

No, I meant API 'stringreverse' function.

The right correct approach depends on priorities, and if that's speed then the correct approach is dictatated by the fact. There's no way around that.

I hope you don't think I'm being too difficult. -_0 Edited February 3, 2013 by guinness

[czardas]

I hope you don't think I'm being too difficult. -_0

It has nothing to do with too difficult. It's about functional code. Some of the speed limitations with AutoIt are just tollerable right now. Any more sluggish and it's usefulness will be severely compromised. That's just something I don't want to see.

Edited February 3, 2013 by czardas

[guinness]

Perhaps I should contact trancexx sometime this week as well.

[kylomas]

I guess you guys don't think to much of my idea to write a string reverse pgm in a lower level language and call it from a UDF similar to the _winapi_* functions...

[czardas]

I think adding new features to AutoIt is fine, just don't break my code which often relys on accurate split second timing. I don't think it's an improvement at all. It will just break lots of stuff, as I see it.

Edited February 3, 2013 by czardas

[guinness]

I guess you guys don't think to much of my idea to write a string reverse pgm in a lower level language and call it from a UDF similar to the _winapi_* functions...

But were back to square one with using lower level languages and it wouldn't be classed as a API function, thus couldn't be labelled _WinAPI.

Before someone mentions it, I will, _WinAPI_MsgBox. I know!

[jchd]

If ever C-style provisions still exist to:

1. Normalize any UTF-16 string into C-form

2. Allocate an output final buffer of the same size as output from 1.

3. Read the output of 1. codepoint by codepoint

4. Write the result at computed address within the result buffer

then by all means, reversing a string can still be made very efficiently if we sacrifice scripts (read: writen languages) using complex graphemes. This can surely be made by inline machine code, like what has been already done for several functions in non-standard UDFs (by Ward IIRC).