_StrToHex()

[SmOke_N]

Not sure why you're not sure.

If you're implying that StringTrimLeft would be faster, it would not. Not on my PC, converting that latin string, at least.

StringTrimLeft is simply moving the ptr to position 2, how could that not be faster?

[Siao]

StringTrimLeft is simply moving the ptr to position 2, how could that not be faster?

By not being as simple as you think?

For what it's worth, in either case the majority of time is spent on StringTrimLeft() and Hex(). StringToBinary() takes the least time to do.

All I know Hex is faster to type in, and runs slightly faster too.

[SmOke_N]

By not being as simple as you think?

I've made the function in other languages.

Char

Char Ptr = *Char + INT Left to Remove

Value = *Ptr

Pretty simple for the memory allocation.

Guess I just don't understand (Unless our StringTrimLeft doesn't do that) how or why Hex would be faster.

Edited April 19, 2008 by SmOke_N

[-Ultima-]

Honestly, it's a debate easily settled with a simple test script:

Global $iIterations = 100000
Global $sTest = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam massa urna, ornare et, pharetra nec, ultrices quis, dui. Pellentesque nec lorem. Fusce pharetra eros. Curabitur varius pede non pede semper iaculis. Mauris vel eros. Aliquam volutpat laoreet purus. Sed tincidunt justo. Nulla sagittis. Nulla facilisi. Etiam volutpat nulla nec libero. Suspendisse sagittis velit eu leo. Donec mattis nisi et ligula. Suspendisse tempus laoreet erat."

; StringTrimLeft()
Global $iTimeTrimDiff, $iTimeTrimStart = TimerInit()
For $i = 0 to $iIterations
    StringTrimLeft(StringToBinary($sTest), 2)
Next
$iTimeTrimDiff = TimerDiff($iTimeTrimStart)

; Hex()
Global $iTimeHexDiff, $iTimeHexStart = TimerInit()
For $i = 0 to $iIterations
    Hex(StringToBinary($sTest))
Next
$iTimeHexDiff = TimerDiff($iTimeHexStart)

; Results
ConsoleWrite(StringFormat("Trim: %.3f ms", $iTimeTrimDiff) & @CRLF)
ConsoleWrite(StringFormat("Hex: %.3f ms", $iTimeHexDiff) & @CRLF)
ConsoleWrite(StringFormat("DIFF: %.3f%%", ($iTimeTrimDiff-$iTimeHexDiff)/$iTimeTrimDiff*100) & @CRLF)

My results:

Trim: 1057.360 ms
Hex: 786.135 ms
DIFF: 25.651%

It makes sense to me that Hex() would be faster anyhow. It's simple an idea to move the pointer over by two, but that's most definitely not how a trim is implemented in AutoIt. StringTrimLeft() returns a copy of the input string with the first X letters trimmed off -- obviously, the copying takes time.

I realize the code is outdated now, but if looking at the source for AutoIt v3.1.0, (I think) I see more memory allocations going on with F_StringTrimLeft() (and any associated assignments, etc) than with F_Hex(). That means more overhead.

As an aside... would it be wise to lose the pointer to the beginning of the string...? How would you fully free the allocated memory?

Edited April 19, 2008 by -Ultima-

[BrettF]

I think it's a good idea - Speed counts!

Speed kills

[SmOke_N]

Honestly, it's a debate easily settled with a simple test script:

Global $iIterations = 100000
Global $sTest = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam massa urna, ornare et, pharetra nec, ultrices quis, dui. Pellentesque nec lorem. Fusce pharetra eros. Curabitur varius pede non pede semper iaculis. Mauris vel eros. Aliquam volutpat laoreet purus. Sed tincidunt justo. Nulla sagittis. Nulla facilisi. Etiam volutpat nulla nec libero. Suspendisse sagittis velit eu leo. Donec mattis nisi et ligula. Suspendisse tempus laoreet erat."

; StringTrimLeft()
Global $iTimeTrimDiff, $iTimeTrimStart = TimerInit()
For $i = 0 to $iIterations
    StringTrimLeft(StringToBinary($sTest), 2)
Next
$iTimeTrimDiff = TimerDiff($iTimeTrimStart)

; Hex()
Global $iTimeHexDiff, $iTimeHexStart = TimerInit()
For $i = 0 to $iIterations
    Hex(StringToBinary($sTest))
Next
$iTimeHexDiff = TimerDiff($iTimeHexStart)

; Results
ConsoleWrite(StringFormat("Trim: %.3f ms", $iTimeTrimDiff) & @CRLF)
ConsoleWrite(StringFormat("Hex: %.3f ms", $iTimeHexDiff) & @CRLF)
ConsoleWrite(StringFormat("DIFF: %.3f%%", ($iTimeTrimDiff-$iTimeHexDiff)/$iTimeTrimDiff*100) & @CRLF)

My results:

Trim: 1057.360 ms
Hex: 786.135 ms
DIFF: 25.651%

It makes sense to me that Hex() would be faster anyhow. It's simple an idea to move the pointer over by two, but that's most definitely not how a trim is implemented in AutoIt. StringTrimLeft() returns a copy of the input string with the first X letters trimmed off -- obviously, the copying takes time.

I realize the code is outdated now, but if looking at the source for AutoIt v3.1.0, (I think) I see more memory allocations going on with F_StringTrimLeft() (and any associated assignments, etc) than with F_Hex(). That means more overhead.

As an aside... would it be wise to lose the pointer to the beginning of the string...? How would you fully free the allocated memory?

I had a feeling it was just an overhead thing if it were faster.

The memory was already allocated, you're just pointing to that address and moving 2.

Edit: (pseudo)

static char szstring;
int nTrimLeft;
static char* ptrst;
ptrst=szstring+nTrimLeft;

Edited April 19, 2008 by SmOke_N