v3.0.103 Unstable - Reloaded

[trids]

possible... try creating your own _StrinReplace() and compare... Anyone wanna create a StringReplace UDF?

Lar.

<{POST_SNAPBACK}>

Taking you laterally ..

Func _StringReplace($psMain, $psOld, $psNew)
    $asX = StringSplit($psMain,$psOld) 
    Return StringJoin($asX,$psNew)
EndFunc

.. Gack! .. no StringJoin

Edit: killed a virtual bug

Edited November 16, 2004 by trids

[SlimShady]

possible... try creating your own _StrinReplace() and compare... Anyone wanna create a StringReplace UDF?

Lar.

<{POST_SNAPBACK}>

I'm working on it...

[SlimShady]

Here it is:

Func _StringReplaceUDF($String, $From, $To, $Count, $CaseSense)
   Local $x
   Local $Match
   Local $Left
   Local $Right
   Local $Length
   Local $NewString
   $Length = StringLen($From)
   $NewString = $String
   $x = 1
   While 1
      $Match = StringInStr($NewString, $From, $CaseSense, $x)
      If $Match = 0 Then ExitLoop
      
      $Left = StringLeft($NewString, $Match - 1)
      $Right = StringTrimLeft($NewString, ($Match - 1) + $Length)
      
      $NewString = $Left & $To & $Right
      
      If $x = $Count Then ExitLoop
      $x = $x + 1
   WEnd
   Return $NewString
EndFunc

[Nutster]

Taking you laterally    ..

Func _StringReplace($psMain, $psOld, $psNew)
    $asX = StringSplit($psMain,$psOld) 
    Return StringJoin($asX,$psNew)
EndFunc

.. Gack!  .. no StringJoin

Edit: killed a virtual bug

<{POST_SNAPBACK}>

I have built and tested ArrayJoin, but it will wait until I get RegExp working for submission. Almost there; just a little more testing. :">

[trids]

I have built and tested ArrayJoin, but it will wait until I get RegExp working for submission.  Almost there; just a little more testing.  :">   

<{POST_SNAPBACK}>

Thanks David, I was just having some fun with the UDF invitation .

I'd be very surprised though, to find a UDF for StringReplace working faster than an intrinsic function designed to do the same thing .. Is UPX clever enought to optimise code to such an extent?

[SlimShady]

Thanks David, I was just having some fun with the UDF invitation  .

I'd be very surprised though, to find a UDF for StringReplace working faster than an intrinsic function designed to do the same thing .. Is UPX clever enought to optimise code to such an extent?

<{POST_SNAPBACK}>

Did you test with my UDF? (See my post above)

I was wondering if it helped you.

[trids]

Did you test with my UDF? (See my post above)

I was wondering if it helped you.

<{POST_SNAPBACK}>

Sorry Slim .. yes, I tested it on the 1000 record file, but canned it after 7 minutes.

Thanks though. But as I say, I'd be surprised if a UDF could out-perform an intrinsic function.

[Jon]

Are you literally saying that StringReplace in the current unstable version is slower than 2 versions ago? If you are then clearly there is a bug. I made a change to the internal string type that I _thought_ and seemed to speed things up (allocating memory on 8byte boundaries) but I could have been way out.

[Holger]

@this-is-me/Jon: I can't see any performance problems with StringReplace

@this-is-me: are your files 'real' textfiles?

So I tested it with a "windowsupdate.log"-file that I copied to my test-script-folder with this script (I replaced all tabs in it with ";" :

$start = TimerInit()
$sFileTXT = @ScriptDir & "\WindowsUpdate.log"
$sFileDAT = @ScriptDir & "\Test.txt"
$sData = FileRead($sFileTXT, FileGetSize($sFileTXT))
$sX = StringReplace($sData, @TAB,";",0,0)
FileWrite($sFileDAT, $sX)
$diff = TimerDiff($start)
Msgbox(0,"Time:",Round($diff / 1000))

$start = TimerInit()
$sFileTXT = FileOpen(@ScriptDir & "\WindowsUpdate.log",0)
$sFileDAT = FileOpen(@ScriptDir & "\Test2.txt",2)
If $sFileTXT = -1 Or $sFileDAT = -1 Then Exit
While 1
    $sData = FileReadLine($sFileTXT)
    If @error = -1 Then ExitLoop
    $sX = StringReplace($sData, @TAB,";",0,0)
    FileWriteLine($sFileDAT, $sX)
Wend
FileClose($sFileDAT)
FileClose($sFileTXT)
$diff = TimerDiff($start)
Msgbox(0,"Time:",Round($diff / 1000))

What I can say: the second method with FileReadLine and FileWriteLine was so much fast than the first

The first method with FileRead() did need 15 seconds and the second like I said did need around 1 second !!!

Thatswhy I said that I see no problem at the moment

Regards Holger

Edit: as I see: notepad does the same like in the second: replacing line by line...

Edited November 17, 2004 by Holger

[this-is-me]

Did I say something?

[trids]

Are you literally saying that StringReplace in the current unstable version is slower than 2 versions ago?  If you are then clearly there is a bug.  I made a change to the internal string type that I _thought_ and seemed to speed things up (allocating memory on 8byte boundaries) but I could have been way out.

<{POST_SNAPBACK}>

I'm saying the last two versions I downloaded are equally slow:

• 2004-10-21 16:30
• 2004-11-15 13:25

I downloaded the last one (on the 15th, Monday) in the hope that the performance might improve. I haven't been able to find an earlier 3.0.103 beta, yet, but I'll let you know if I do.

Meantime, I'll try Holger's idea of StringReplace-ing line by line .. I confess this is intuitively slower to me than one FileRread and a single StringReplace, so I haven't tried it yet.

Edit: spelling

Edited November 17, 2004 by trids

[trids]

Awesome - Thanks Holger! .. the line-by-line approach yields the following improved results:

• 1,000 lines = 2 to 3 seconds
• 15,000 lines in 9 to 10 seconds (1.8Mb file) .. twice as fast as TextPad even!

So. Any ideas why it's so much faster to StringReplace multiple tiny strings than a single string equal to the sum of all the parts?

Is this proof of "synergy"?

.. or is there some size-limit to the efficiency of StringReplace?

[Henrik]

So.    Any ideas why it's so much faster to StringReplace multiple tiny strings than a single string equal to the sum of all the parts?

<{POST_SNAPBACK}>

Slicing and/or concatenating (large) strings are time-consuming operations.

Some colleagues of mine had to troubleshoot a project where the original project team had given up making the application perform as specified. The troubleshooters changed the string operations to work with pointers/references instead of manipulating the actual strings & increased performance by approx. a factor 100.

[Jon]

Any ideas why it's so much faster to StringReplace multiple tiny strings than a single string equal to the sum of all the parts?

Oh I missed that part in the orginal post.

The way a single string is allocated is that you have x charcters and it allocates memory for that amount. Then you add something to it and because you have no more room you have to allocate an entire new block of memory that can hold the old string plus the new additional stuff, copy the string and then free the original block (this is simplified - I actually allocate new memory by leaving room for the string to double in size, but still...). Memory allocation is sloooow, so concatenating such a large "string" will pretty much kill the system

Edit: oh, and addition the variable might be copied a couple of times internally during operations so that means allocating the memory again, which will start to grind at big sizes. I've just thought of a way to speed up stringreplace quite a bit though.

Edited November 17, 2004 by Jon

[trids]

Ok .. thanks, it helps to get a handle on things

[Jon]

Updated:

(note: David, JP, holger have submitted loads of more stuff too but I only had a short time today/this week)

- GuiCtrlCreateDummy()

- RegExp, RegExpSet, RegExpClose

I have NO idea if the regexp stuff works, i don't understand them at all so I'll have to rely on you/Nutster

J.

[Jon]

http://www.autoitscript.com/autoit3/files/unstable/autoit/

Updated:

- Default function parameters (Ta JP)

- StringSplit now accepts full string delimiters too (Ta Nutster)

- The directive #NoTrayIcon stops the icon from initially being shown (I wanted to do it by checking for a Opt() command at the top of the script but "top" of the script is meaningless when you have GuiConstants and all sorts)

Funcs:

Test(1)

Func Test($myvar1, $myvar2 = 200)
  MsgBox(0, "Number of parameters:", @NumParams)
  MsgBox(0, "Param1:", $myvar1)
  MsgBox(0, "Param2:", $myvar2)
EndFunc

The @NumParams thing is great as you can even tell the difference between a "default" value and no value at all.

Edited November 27, 2004 by Jon

[Valik]

Wow. I didn't expect default parameters so soon. Awesome.

[CyberSlug]

- The directive #NoTrayIcon stops the icon from initially being shown (I wanted to do

<{POST_SNAPBACK}>

I don't see this documented in the help file... trying to keep this one a secret?

Excellent work on all the new functions

[this-is-me]

*I love you all*