Recently Browsing 0 members
No registered users viewing this page.
I've noticed that for the task of "reading a file row by row into an array" FileReadToArray is consistently slower than a FileRead + StringSplit.
The following script:
Results in the following output for me:
And the output with switched call sequence:
This surprises me, since I first assume that the native function offers more optimization possibilities than having to create an array in AutoIt via an intermediate string.
So I thought that maybe FileReadToArray is more economical with memory. But again FileReadToArray seems to consume more memory than the StringSplit variant. For this I got the PeakWorkingSetSize after the call of the respective function.
After FileReadToArray the Size is always higher than with StringSplit. Since this is not the case if one changes the order of the two functions (see above), one can assume that FileReadToArray actually has this difference. The difference is mostly the double file size. Which would make sense if the file is completely saved internally as a UTF-16 string.
Can anyone explain to me why FileReadToArray performs so unexpectedly poor - or am I missing something?
Developers, can anyone explain this phenomenon to me?
Run this code and wait for nothing without doing a few minutes and you will start receiving randomly, either one or the second message. But none of them should never appear on the logic of the code!
As I understand sometimes the function ClipGet () returns an empty value. Why is this happening?
Dim $ClipGetText ClipPut("12345") While 1 Sleep(5) ;reduced to 5 to better see the problem if ClipGet()<>$ClipGetText And ClipGet()<>"" Then $ClipGetText=ClipGet() Beep(800,100) ConsoleWrite(ClipGet()&"|"&$ClipGetText&@CRLF) ElseIf ClipGet()="" Then Beep(800,100) ConsoleWrite("Empty"&@CRLF) EndIf WEnd
I have problem with ClipGet () function: If the clipboard contains a large amount of data the use of the function pushes the consumption of cpu resources to 100% and my script unresponds until I force it to end.
I tried to work around the problem by limiting the size of the recovered data from the clipboard
Local = $ClipBoardData = StringMid(ClipGet (), 1.1024) I also used:
DllCall ("psapi.dll", "int", "EmptyWorkingSet", "long", -1) to free the memory after each call to ClipGet ()