Custom Query

Script:

; create a very large string (should be about 400 MB because UTF-16 is used)
Global $sString = ""
For $i = 1 To 20 * 1024 * 1024
    $sString &= "xxxxxxxxxx"
Next

; precompile pattern
StringRegExp("", "^.")

; determine time required for a small input string:
$iT = TimerInit()
StringRegExp("Test", "^.")
ConsoleWrite(StringFormat("RegEx with small input string: % 8.3f ms\n", TimerDiff($iT)))

; determine time required for a large input string:
$iT = TimerInit()
StringRegExp($sString, "^.")
ConsoleWrite(StringFormat("RegEx with large input string: % 6.1f   ms\n", TimerDiff($iT)))

Output:

RegEx with small input string:    0.012 ms
RegEx with large input string:  328.1   ms

The execution time depends directly on the size of the input string although only the first character of the string is processed. If instead of StringRegExp a StringLeft or a StringMid is used then the execution times are independent of this.

This leads to the assumption that in the implementation of StringRegExp() at some point the input string is passed as "by value". This would require the creation of a local copy of the string and would explain the loss of time.

If it is really a "by value" problem, i suggest to switch completely to "by reference" internally if possible. This would mean a massive performance gain for StringRegExp especially with large strings.

Following Script:

$sIntUpper = "12345E5"
$sIntLower = "12345e5"

$sFloatUpper = "1.2345E5"
$sFloatLower = "1.2345e5"

ConsoleWrite(StringFormat("\n     xxx -> Number(xxx)\n% 8s -> %10d (Type: %s)\n% 8s -> %10.0f (Type: %s)\n% 8s -> %10.0f (Type: %s)\n% 8s -> %10.0f (Type: %s)\n\n", _
        $sIntUpper, Number($sIntUpper), VarGetType(Number($sIntUpper)), _
        $sIntLower, Number($sIntLower), VarGetType(Number($sIntLower)), _
        $sFloatUpper, Number($sFloatUpper), VarGetType(Number($sFloatUpper)), _
        $sFloatLower, Number($sFloatLower), VarGetType(Number($sFloatLower)) ))

produces:

     xxx -> Number(xxx)
 12345E5 ->      12345 (Type: Int32)
 12345e5 -> 1234500000 (Type: Double)
1.2345E5 ->     123450 (Type: Double)
1.2345e5 ->     123450 (Type: Double)

The capitalized letter "E" is recognized as an exponential character only if a decimal separator appears before it.

This is not the case for the lowercase "e".

Following script:

$fN = 562949953421312.0
$iN = Int($fN, 2)
$iN2 = Number($iN, 2)

ConsoleWrite("$fN :" & $fN & " (" & VarGetType($fN) & ")" & @CRLF & _
	"$iN :" & $iN & " (" & VarGetType($iN) & ")" & @CRLF & _
	"$iN2:" & $iN2 & " (" & VarGetType($iN2) & ")" & @CRLF)

produces:

$fN :562949953421312 (Double) $iN :562949953421313 (Int64) $iN2:562949953421313 (Int64)

This applies to all integer numbers >= 2⁴⁹ stored as double.

The numbers themselves can be mapped completely and without rounding errors in IEEE 754 double precision.

The naive approach to implementing an Int() function would be a C-type cast ((long long) fValue)) or a C++-typecast (static_cast<long long>(fValue)). However, these do not exhibit the problem:

#include <iostream>

using namespace std;

int main()
{
    double f = 562949953421312.0;
    long long iInt1 = (long long)f;
    long long iInt2 = static_cast<long long>(f);
    
    cout<<iInt1<<"\n"<<iInt2;
}

In old public source codes of AutoIt also the C-cast was used for the Int() function ((__int64)m_fValue in method n64Value in file variant_datatype.cpp). In the meantime, however, there has apparently been a change here.