JavaScript vs AutoHotKey (Simple Speed Test)

Discuss other programming languages besides AutoHotkey
User
Posts: 407
Joined: 26 Jun 2017, 08:12

JavaScript vs AutoHotKey (Simple Speed Test)

31 Jan 2019, 18:58

Wow, now I am really surprised!

I wrote "Is()" function (click here) for AutoHotKey just to test speed! (which is really slow, it takes 14000 milliseconds (14 seconds) to compare 2 strings of ~= 20 megabytes each!)

I decided to write the same function for JavaScript (almost a clone), and I was expecting it to be 10x to 20x slower than "Is()" function from AHK!

Guess what, "Is()" function from JavaScript takes only 741 milliseconds (less than 1 second) to compare 2 strings of ~= 20 megabytes each!

Wow, what'a surprise! It would suggest that, even JavaScript, is almost 19x faster than AHK?

[OBS]: I searched google and found out that most people agrees that JavaScript in fact compiles the whole script and then execute the machine\byte code?

Anyway, "Is()" function for JavaScript:
Is() - JavaScript.png
Is() - JavaScript.png (4.38 KiB) Viewed 13817 times

Code: Select all

<!DOCTYPE html>

<script>

x = "A";

for (i = 0; i < 20100100; i++) {x += "a";};

y = x;

x += "A";
y += "B";

Start_Time = new Date().getTime();

if (x == y)
{alert("yes (" + (new Date().getTime() - Start_Time) + " milliseconds)");}
else
{alert("no (" + (new Date().getTime() - Start_Time) + " milliseconds)");} 

alert(Is(x, "=", y));


function Is(String1, Operator, String2) {	//_________________________

var Char_1; var Char_2;	var Index = 0;		//"var" statement makes variables "local" inside functions

var Start_Time = new Date().getTime();

	for (;;) {	//Infinite loop
	
	Index++;

	Char_1 = String1.substring(Index - 1, Index);
	Char_2 = String2.substring(Index - 1, Index);

		if (Char_1 == Char_2)
		{
		if (Char_1 == "" && Char_2 == "") {return "yes (" + (new Date().getTime() - Start_Time) + " milliseconds)"};
		} 
		else
		{
		return "" 
		+ "no (" + (new Date().getTime() - Start_Time) + " milliseconds)"    + "\n"
		+ "\n"
		+ "Difference found at string position " + Index    + "\n"
		+ "\n"
		+ "(" + Char_1 + ") != (" + Char_2    + ")\n\n\n"
		};
	
	};

};


</Script>
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

31 Jan 2019, 22:56

I don't recall ever reading that the creator of AutoHotkey was trying to make the fastest scripting language on Earth. I thought the point was more along the lines of automation and a language that was easy to use, with easy to understand syntax, so that even non-programmers could use it. The counter-argument is that AutoHotkey is fast enough for general use and the vast majority of users. Where it's not fast enough, users are free to add machine code or mix in other programming languages into their AutoHotkey script.

Your test is not the be all, says all, in regards to comparing JavaScript to AutoHotkey. Languages with very different purposes and goals. If a person is so overwhelmed with the "need for speed", they could program in Assembly. Have fun with that, and good luck to you. However, if you are that smart and such an expert programmer, instead of trolling AutoHotkey, why not contribute to the source code to make it faster? Also, nobody is stopping you from forking the very open source AutoHotkey, and making your better and faster version.

As for the link to your script in the other thread. You never addressed swagfag's solution, minus trolling and insults, nor did you address the comments and constructive suggestions made by jeeswg.

Hint- make some changes to numbers or zeros around here, and you won't get any memory errors.

Code: Select all

VarSetCapacity(temp_a, (temp_chars := 100000) * 2)
Loop % temp_chars
	temp_a .= "a"

global NUM_CHARS := 2000 * 1000000 ; in millions
VarSetCapacity(x, NUM_CHARS * 2 + 2)
loop % NUM_CHARS / temp_chars
x .= temp_a
Complete script

Code: Select all

#NoEnv
SetBatchLines -1
ListLines Off


DllCall("LoadLibrary", "Str", "msvcrt.dll", "Ptr")

gui, add, text, w200 h100, please wait
gui, show

VarSetCapacity(temp_a, (temp_chars := 100000) * 2)
Loop % temp_chars
	temp_a .= "a"

global NUM_CHARS := 2000 * 1000000 ; in millions
VarSetCapacity(x, NUM_CHARS * 2 + 2)
loop % NUM_CHARS / temp_chars
x .= temp_a

VarSetCapacity(y, NUM_CHARS * 2 + 2)
y := x

x .= "a"
y .= "a"
; y .= "b"
++NUM_CHARS

Start := A_TickCount

if (x = y)
{
gui, hide
msgbox, % "yes (" A_TickCount - Start " milliseconds)"  
}
else
{
gui, hide
msgbox, % "no (" A_TickCount - Start " milliseconds)"  
}

gui, show

msgbox, % Is(x, "=", y)

guiclose:	;_______________
exitapp



Is(ByRef String_1, Operator, ByRef String_2)	;___________________
{

	Start := A_TickCount

	if DllCall("msvcrt.dll\memcmp", "Ptr", &String_1, "Ptr", &String_2, "Int", NUM_CHARS * (A_IsUnicode ? 2 : 1), "Int")
	{
	gui, hide
	return "no (" A_TickCount - Start " milliseconds)"  
	}
	else
	{
	gui, hide
	return "yes (" A_TickCount - Start " milliseconds)"  
	}
}
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 03:17

That's a case sensitive comparison therefore pointless.
Most people don't want to code in C but rather in AutoHotkey when they choose the AutoHotkey language.

The speed of a language is defined by its primitives not by its methods of including other languages. So arguments like MCode and DLLs are both besides the point and pointless - especially so when you don't use MCode yourself and don't understand its massive issues.

Therefore Users assessment is closer than yours but also completely off. In js every string is also an array - so there is no conversion taking place, obviously giving js an unfair advantage in this case. Also looking at his code he doesn't even seem to measure the is function itself only the String comparison.

Regardless I don't want any of the participants of the last conversation to continue it.
Recommends AHK Studio
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 10:50

SOTE wrote:
31 Jan 2019, 22:56
Hehe, I'm not trolling AHK!

I'm just saying that, yes, it's clear that AHK is a very slow language! (Even a very simple function written in AHK can be really really slow!)

AHK should be fast enough for some Windows Os and Games automation tasks! But, it is not recommended for data-processing and string manipulation in general!

Hell, even JavaScript is almost 19x faster than AHK!

Your code example has nothing to do with "Is()" function purpose, so, it's pointless! (and it makes unnecessary use of dll, varsetcapacity, etc, ect, please!)

In order to make AHK a little bit faster language it is required the use of c\c++, machine codes, dll, etc, etc! (No, Thanks!)

swagfag's solution is really 100% shitty! (He knows that!)

[Obs]: no c\c++, machine code, dll, varsetcapacity, etc, etc, was used in the Javascrit code, and yet it is 19x faster than AHK! Wow, that's impressive!

Why opting to "Assembly" if I can use Javascript that is 19x faster than AHK?

NewComer: Should I use AHK for heavy data-processing and string manipulation?

Everybody should\must say: Hell no, you rather use javascript instead!
gregster
Posts: 8916
Joined: 30 Sep 2013, 06:48

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 11:10

Fine, case closed.
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 11:12

nnnik wrote:
01 Feb 2019, 03:17
Also looking at his code he doesn't even seem to measure the is function itself only the String comparison.
alert(Is(x, "=", y))

javascript String comparison (450 milliseconds) is faster than "Is()" function (741 milliseconds)!

That's understandable because "Is()" function do extra tasks in order to return the string position where the 2 strings don't match each others! (and it returns the 2 found characters that don't match each others!)
Last edited by User on 01 Feb 2019, 11:19, edited 1 time in total.
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 11:14

gregster wrote:
01 Feb 2019, 11:10
Fine, case closed.
Hehe! Thank you Mister Judge!
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 11:23

User wrote:
01 Feb 2019, 10:50

Hehe, I'm not trolling AHK!
User wrote:
01 Feb 2019, 11:14
gregster wrote:
01 Feb 2019, 11:10
Fine, case closed.
Hehe! Thank you Mister Judge!
You say that you are not trolling, so then I don't understand pushing this any further. Just go use JavaScript and be happy.

And anybody can use both, just write a AutoHotkey script that contains JavaScript in it (or other language). Here's a video from NadjibSoft showing how. If he can do it, then anybody can.
https://youtu.be/ITRBOKhX8io
(Merge Javascript & AutoHotkey)
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 11:35

SOTE wrote:
01 Feb 2019, 11:23
Hehe! Of course I'm going to use Javascript more oftenly now! (Thanks for your recommendation!)

I'm not pushing anything further, I'm just sharing a script from another language and compare it with AHK in "Other Programming Languages" forum!

If you don't like "Other Programming Languages" forum, just don't visit it anymore and be happy!

"And anybody can use both" (Nah, I rather use JavaScript alone! Again, thanks for your recommendation!)
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

01 Feb 2019, 23:10

If not trolling, a person would debatably just introduce the language they are interested in. Like "Intro To JavaScript" or "The Joys Of JavaScript". I wouldn't go to a JavaScript forum and troll them about how deficient their language is when it comes to automation, various syntax, or popularity of use on desktops. I'm sure a lot of them would tell me to go enjoy AutoHotkey or use both, and be happy. There really isn't any need to insult one thing, in order to hype another.

AutoHotkey and JavaScript are not in competition with each other, but are instead languages that can use each other. They were designed for different purposes and have different goals. They also have different strengths and weaknesses, and a smart programmer will understand how to utilize the tools he has to accomplish the task.

When it comes to accomplishing a task, be it data processing or string manipulation (or whatever), there can be different ways to go about it. Where one programmer is completely blind to alternative ways of going about something, while another succeeds by going a different route than usual or is the conventional. Sometimes the solution is to break down a task into smaller parts or to look at it in a different way, versus brute force or expecting the answer will be solved exactly the way one was taught in school. Sometimes the programmer/person must put their ego in check, and not think their code is "perfect", so that there isn't any other way to solve a problem.

With that typed, people have their preferences, and justifications for their prejudices. But it might be best for us to remember that we can all have different opinions about what is best. So do what is best for you, be it personally or at your job, but let's not insist or bash others over the head to force them to agree. Perhaps it's just best to agree, to disagree.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 02:49

- @User: Do you enjoy claiming that AutoHotkey is slow for some reason? :crazy:
- Firstly, I'd say that AutoHotkey is sufficiently fast to justify existing, and sufficiently fast for my liking (by using dll calls or machine code if necessary), furthermore I have high standards when it comes to speed requirements.
- Secondly, if you want to benchmark AutoHotkey against other languages that's fine, but you should try comparing a wide-range of features.
- Thirdly, make sure you're comparing like with like. E.g. are you comparing a built-in feature of JavaScript with a suboptimally-implemented custom function in AutoHotkey.
- Fourthly, AutoHotkey introduces built-in functionality only when widely needed. It is understood that further functionality could be implemented via AHK code/dll calls/machine code. If you think AutoHotkey needs a new built-in feature, you can post in the Wish List forum.

- @nnnik: It's fair to compare language X versus language Y (allowing or disallowing dll calls and machine code, as long as you specify it). I.e. as long as something is a fair comparison that's all that matters, and the more useful fair comparison is to allow the use of dll calls and machine code.

- Here's some better code for comparing strings, case-sensitive and case-insensitive.

Code: Select all

q:: ;case-sensitive/case-insensitive comparisons
;VarSetCapacity(x, 20100100*2+2)
;Loop, 20100100
;	x .= "a"
x := StrReplace(Format("{:20100100}", ""), " ", "a")
y := x
x .= "A"
y .= "a"

Clipboard .= "`r`n" "BENCHMARK TEST:"
vSize := StrLen(x)*2
MsgBox, % "vars ready"

;case-sensitive comparison
vTickCount := A_TickCount
vRet := DllCall("ntdll\RtlCompareMemory", Ptr,&x, Ptr,&y, UPtr,vSize, UPtr)
Clipboard .= "`r`n" (A_TickCount - vTickCount)
MsgBox, % vRet " " (vRet = vSize)

;case-insensitive comparison
vTickCount := A_TickCount
x := Format("{:L}", x)
, y := Format("{:L}", y)
, vRet := DllCall("ntdll\RtlCompareMemory", Ptr,&x, Ptr,&y, UPtr,vSize, UPtr)
Clipboard .= "`t" (A_TickCount - vTickCount)
MsgBox, % vRet " " (vRet = vSize)
return

;e.g. results
;32	655
;32	671
;16	655
- @User: Your comparison is an interesting one. For code that looks quite similar, you're getting a much faster result in JavaScript. As nnnik mentioned, it could be that the string is stored differently.
- What do people think? Should AutoHotkey introduce a string array, should AutoHotkey replace the current string implementation with a string array, or would there be disadvantages to doing that?
- AutoHotkey can make use of an external Scripting.Dictionary object to store key-value pairs, is there an external object type available for a string array?
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 04:41

Your code is still incorrect - it doesn't give the correct position of the character that's different. You also double up the memory usage of both strings - a fatal flaw if you compare really big strings.
It's pointless to compare the speed of 2 languages if they both offer a method of calling C code in your way. You would end up comparing the speed of C and the overhead of the calling mechanism. MCode and DLLCall needs to be disregarded - just like you disregarded Javascripts own possibilities in that regard.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 05:05

- Re. bytes v. char count, I wanted to demonstrate the basic principle. (A proper script could add in division by 2, that's not too difficult. One thing you didn't mention is ANSI v. Unicode versions of AHK.)
- Re. copying strings. I wanted to demonstrate a fast but simple case-insensitive example. (A proper script could avoid copying strings by comparing byte by byte. Do you have any other ideas?) (That 3-line code may be faster for some string sizes than using machine code.)
- Why not post some AHK code that is as optimised as possible?
- Many code variations in both languages are worth benchmarking for different reasons. With/without DllCall/MCode etc.
- The one problem with AHK is that using Loop and SubStr/NumGet is slow for reasonably small amounts of data, and the few times I've used machine code, it's been to do that. Maybe it would be worth considering a new feature (object type) to handle this.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 05:54

jeeswg wrote:
02 Feb 2019, 02:49
are you comparing a built-in feature of JavaScript with a suboptimally-implemented custom function in AutoHotkey.
Hehe, "Is()" function is not a built-in feature neither in AHK nor Javascript!

They are basically a clone of each other, and both of them use built-in "Subtring()" functions of the correspondent language!
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 05:55

Even when you divide by 2 you won't get the correct result. 2 bytes is not 1 character - see the higher unicode plains.
Yeah Loop and SubStr are the fastest you will get in AutoHotkey - which is incredibly slow.
However we could reduce the complexity a lot by essentially cutting the strings in half each time we compare the strings and finding the half the error is in:

Code: Select all

x := StrReplace(Format("{:20100100}", ""), " ", "a")
y := x . "A"
x .= "B"
SetBatchLines, -1
qSortErrorLookup(x, y)
qSortErrorLookup(x, y)
qSortErrorLookup(x, y)
;a few dry runs
start := A_TickCount
difference := qSortErrorLookup(x, y)
total := A_TickCount - start
Msgbox % Clipboard := "Found difference at character position: " . difference . "`ntook " . total . " ms"

;Found difference at character position: 20100101
;took 156 ms
;Found difference at character position: 20100101
;took 141 ms
;Found difference at character position: 20100101
;took 172 ms

qSortErrorLookup(byref string1, byref string2, partCount := 2) {
	Local
	if (string1 = string2) {
		return false
	}
	
	cLeftBorder := 1
	cLen := max(strLen(string1), strLen(string2))
	loop {
		stepSize := (cLen)/partCount
		leftBorder := cLeftBorder
		loop %partCount% {
			leftB := round(leftBorder)
			len := Round((leftBorder+=stepSize)-leftB)
			if (subStr(string1, leftB, len) != subStr(string2, leftB, len)) {
				if (len = 1)
					return leftB
				cLeftBorder := leftB
				cLen := len
				break
			}
		}
	}
	return false
}
It's not perfect - e.g. I dont deal with characters from higher unicode plains correctly and it could also be made faster by avoiding the last lookup/comparison. (since we already know that the error is in there)
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 06:23

- Thanks for sharing, that's great as a truly native solution.
- Ironically, when code gets as fiddly as that, MCode becomes the easier option.
- Out of interest, do we not have the same problem of copying variables? Although in this case, only half of a variable (then a quarter, eighth etc).
- (Btw where you put cLen := max(, did you mean min?)
- I used this to test it: NumPut(Ord("z"), &x, 10000000, "UShort")

- (Yeah, every time I go on Stack Overflow, re. anything 'case insensitive' there's always a massive debate about surrogate pairs/combining characters and quirks re. what things are considered identical in different languages, and what constitutes a character. And does sharp s Chr(223) equal 'ss' etc.)
Last edited by jeeswg on 02 Feb 2019, 06:29, edited 2 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 06:28

ß doesn't equal ss. I don't really think MCode would have been any easier or even faster/useful for case insensitive comparisons since MCode cannot call any C standard library functions without some trickery.
A dll might have been faster but carrying around a dll isn't really fun is it?
(Btw did you mean cLen := max(, rather than min.)
But it says max???

BTW it seems that this option is faster than using Format to turn the strings into their lower counterparts.
Recommends AHK Studio
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 06:34

I don't understand this false restriction of not being allowed to use MCode or DllCalls. OK, maybe from a purist's point of view, but AutoHotkey is a scripting language using a C++ Interpreter. It's not a compiled language, so by default, there is going to be various trade-offs. Speed being one of the most famous ones. JavaScript was initially an interpreted language too (with it's interpreter written in C), but many implementations of it use a JIT compiler and they have various JavaScript engines out there.

To gain more speed, AutoHotkey is going to have to rely on various methods like MCode or DllCalls, to include using other languages inside of the script. Otherwise, we are talking updating the source code with some new functions (though it's unclear if needed), coming out with a new Interpreter, JIT compilation, transpilers, or turning it into a compiled language.

I'm of the mind that an apples to apples comparison can't really be done, and if it could, it's arguably pointless. Performance would be relevant to scripts doing real world tasks, and depends on the needs or expectations of the person who made it. With AutoHotkey, the person would usually add something into his script, as a workaround. When you look at the forums, that's been common practice for many years. People have been stuffing in VBScripts, JavaScripts, calling exes and dlls from other languages, etc... for a long time. And if AutoHotkey got new capabilities, this often came from the developers or users good at C++ that made new functions/code.

I would be curious, on what task that AutoHotkey couldn't do. Like bring it to the forums, share the actual problem, and let other people look at the code. Not any trolling, but legitimately ask for help on the task or project. If the person doesn't want to be up front, and share the code, then why complain? If the person is suffering because they can't figure out a solution by themselves, it looks unfair to take their frustrations out on the AutoHotkey community. If AutoHotkey needs a new feature or updated source code, that's arguably a better way to go about it. More people would see the issue, and then the possibility of someone thinking up a solution increases. Even with what User did, people are already evaluating the code and looking for ways to tweak and rewrite new code, even if the context isn't truly apples to apples or for a real world problem.
Last edited by SOTE on 02 Feb 2019, 06:43, edited 1 time in total.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 06:42

- @nnnik: Re. 'it says max', I updated my post. I thought that maybe it should be 'min', because when you compare 2 strings, you only compare up to the length of the smaller one.
- Yes, it does appear to be faster. Is Format quite slow then!?

- @SOTE: Yes I'd let either language use DllCall/MCode etc in comparisons.
- My concerns in any language are: to find the fastest method, but also to find a method that is both simple/readable and reasonably fast (sometimes in order to test the output for the fastest method), and sometimes to find a method than can be tweaked if more criteria is needed.

- @User: Yes, initially I thought you were using a built-in JavaScript function, I double-checked this before posting and found that it wasn't built-in, and so updated my post starting at: 'Your comparison is an interesting one'. Cheers.
Last edited by jeeswg on 02 Feb 2019, 06:56, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 06:55

Code: Select all

#MaxMem 4095

x := StrReplace(Format("{:201001000}", ""), " ", "a")
y := x . "A"
x .= "B"

q::
SetBatchLines, -1
;case-insensitive comparison
vTickCount := A_TickCount
vSize := StrLen(x)*2
x1 := Format("{:L}", x)
y1 := Format("{:L}", y)
vRet := DllCall("ntdll\RtlCompareMemory", Ptr,&x1, Ptr,&y1, UPtr,vSize, UPtr)
x1 := ""
y1 := ""
MsgBox, % Clipboard := ";Found difference at: " . vRet . " took " . (A_TickCount - vTickCount) " ms"

;Found difference at: 402002000 took 5813 ms
;Found difference at: 402002000 took 5516 ms

start := A_TickCount
difference := qSortErrorLookup(x, y)
total := A_TickCount - start
Msgbox % Clipboard := ";Found difference at: " . difference . " took " . total . " ms"

;Found difference at: 201001001 took 1718 ms
;Found difference at: 201001001 took 1719 ms

qSortErrorLookup(byref string1, byref string2, partCount := 2) {
	Local
	if (string1 = string2) {
		return false
	}
	
	cLeftBorder := 1
	cLen := max(strLen(string1), strLen(string2))
	loop {
		stepSize := (cLen)/partCount
		leftBorder := cLeftBorder
		loop %partCount% {
			leftB := round(leftBorder)
			len := Round((leftBorder+=stepSize)-leftB)
			if (subStr(string1, leftB, len) != subStr(string2, leftB, len)) {
				if (len = 1)
					return leftB
				cLeftBorder := leftB
				cLen := len
				break
			}
		}
	}
	return false
}
@SOTE:
The comparisons between languages is about the languages themselves - not how you could extend them using external languages.
When you consider the possibility of extending the language you could also consider rewriting the interpreter itself as part of the languages speed - becuase why not.
However that doesn't give you any valid information about the strengths and weaknesses of the language and it's own features on its own.
On it's own AutoHotkey is a decently fast Interpreted languages that has a few massive speed blocks that prevents specific styles from being fast.
Want to write code in OOP thats sufficiently fast - don't use AHK. Want to write it all in the native language without having to rely on specific OS features or interact with the OS by yourself on a really low level - don't use AutoHotkey.
You require performance - don't use AutoHotkey.

This is not some sort of pointless my thing is the largest thing comparison - we are trying to get valid data about languages here.

@jeeswg I think it's because we essentially change a few thousand bits bit by bit where as in my script we only copy and use the case insensitive comparison.
It's the same reason BubbleSort is slower than SelectionSort although being equally complex in comparisons.
Recommends AHK Studio

Return to “Other Programming Languages”

Who is online

Users browsing this forum: No registered users and 25 guests