JavaScript vs AutoHotKey (Simple Speed Test)

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

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 07:02

The truth is that, any task that requires heavy loop iteration (Say, 15000+ iterations) is slow to very slow in AHK!

So, heavy loop iteration should be avoided in AHK! (even when using c\c++, machine codes, dll, etc, etc, workarounds!)
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 07:07

You are wrong about how AHKs Interpreter works - I never bothered correcting you though.
The interpreter turns all AHK code into a token form when it starts - then it executes these tokens.
Recommends AHK Studio
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 07:16

nnnik wrote:
02 Feb 2019, 07:07
Regardless of how the AHK interpreter works, heavy loop iteration should be avoided in AHK because it is really slow to very slow!

For example, from the example code I posted in this thread's main post, we could say that javascript loop for(;;) is 19x faster than AHK loop!
gregster
Posts: 8916
Joined: 30 Sep 2013, 06:48

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 07:17

jeeswg wrote:
02 Feb 2019, 06:23
And does sharp s Chr(223) equal 'ss' etc.
Like always, it depends :). But no, not generally.

In Germany you will only use 'ss' as a workaround for 'ß', if the letter 'ß' is not available (like 'ae' for ä, if there are no umlauts available).
On the other hand, there are words with ss that never get written with ß. ß is usually used after long vowels (Straße; eine Maß Bier (bad example actually, locally it is also Mass with a short a)) or double vowels that sound long (Scheiße), ss after short vowels (Kuss) - and it depends sometimes on local pronunciation: in Austria, Spaß and Spass both exist - it's fun :)

Then again, until 1996's spelling reform it was Kuß instead of Kuss (in Germany) - while in Liechtenstein and Switzerland, german-speaking people never use ß - always ss.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

02 Feb 2019, 07:44

Hello gregster. I think I read in some debate on Stack Overflow re. comparing strings, should the versions with/without eszett be considered identical. I don't know if this is commonly done or not e.g. when sorting words. Anyway, I like the special letter, and thanks for the info about it.
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, 15:41

Well, thinking better, "AHK is slow" is not all that correct!

But, heavy loop iteration in AHK is slow to very slow! (Should be avoided! The problem is that the use of "loop" is oftenly required to write functions and to do others things!)

For example, "Sort" command even for large strings is somehow fast, maybe because the code behind "Sort" command is pure C\C++ code?
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 00:59

User wrote:
02 Feb 2019, 07:02
The truth is that, any task that requires heavy loop iteration (Say, 15000+ iterations) is slow to very slow in AHK!

So, heavy loop iteration should be avoided in AHK! (even when using c\c++, machine codes, dll, etc, etc, workarounds!)
But, heavy loop iteration in AHK is slow to very slow! (Should be avoided! The problem is that the use of "loop" is oftenly required to write functions and to do others things!)
When we are talking loops, let's also point out the issue of nested loops. This can cause a speed problem, regardless of programming language and has nothing to do with an actual flaw in AutoHotkey, but rather a problem in the coding style of the programmer. It's not to say that a nested loop is always bad, in fact it could be necessary, but is something to look for if speed is such an issue.

If an algorithm contains a bunch of nested loops, then it can be slowing it down. Along those lines, one can have a lot of convoluted and unnecessary code, that is also causing a loss in speed. It can often be the better practice to separate these loops, verify how necessary they are, or rethink the code.

And when used properly, loops are great. Though, I would like to add, that I'm curious about how different types of loops might affect the speed of a script. But still, it's a matter of what the programmer is trying to achieve. This again goes back to the person looking at their code and thinking about ways to simplify it or make it more efficient. I've been reading on the term Compression-Orientated Programming. Where you write code that works at first or the simplest code that you can, but also go back and reevaluate it and see if there is any duplication, redundancies, inefficiency, other ways to simplify, etc... Though I want to throw some caution out there, because arguably working code or faster to create code, can be the better option due to time constraints or the lesser of two evils.
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 08:53

SOTE wrote:
03 Feb 2019, 00:59
This can cause a speed problem, regardless of programming language and has nothing to do with an actual flaw in AutoHotkey ...
Now you are trying to argue that AHK loop is not slow to really slow?

Can't you see that from the "Is()" function examples I posted above that AHK loop is in fact slow?

The "Is()" function examples use only 1 simple loop (no nested loop), and yet it is fast in Javscript and really really slow in AHK! (Please be coherent in this matter!)

If Javascript loop f(;;) seems to be 19x faster than AHK loop, hell, I can imagine that loop from C\C++, C#, Java, may be 50x to 100x faster or even more! (or maybe not! I forgot that, based on what I searched on google, it seems that javascript in fact compile its scripts before execution, so, in terms of speed, javascript may be the same or just a little bit slower than C\C++, C#, Java, etc, etc, etc! Who knows?)
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 09:06

@User then again I posted an example which is extremly fast.
Could you implement the same algorythm in javascript to see it's speed?
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 09:55

- Using StringLower is around 3 times faster than using Format.
- Would the fact that Format needs to parse the text checking for { and } have something to do with it?

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
StringLower, x, % x
StringLower, y, % 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
;31	219
;31	203
;31	219
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)

03 Feb 2019, 10:26

nnnik wrote:
03 Feb 2019, 09:06
I didn't test your code, but I think you should remove "Local" statement (because not everybody uses AHK 1.1.27+) and should use cLen := strLen(string1) >= strLen(string2) ? strLen(string1) : strLen(string2) (because not everybody has max() function in their library), otherwise, most of people here can't test your code!

Saying that, the matter here is not how to make "Is()" function more efficient anymore!

The "Is()" function examples demonstrate that, for the same amount of loop iterations, AHK lags behind Javascript ~= 19x time! (Suggesting that AHK loop is in fact really slow!)

Of course "Is()" function can be made more efficient in AHK by avoiding less loop iterations in many ways!

But there are a lot of situations where heavy loop iteration is a must and can't be avoided! (so in these situations, AHK is not recommended!)
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 11:11

User wrote:
03 Feb 2019, 10:26
nnnik wrote:
03 Feb 2019, 09:06
I didn't test your code, but I think you should remove "Local" statement (because not everybody uses AHK 1.1.27+) and should use cLen := strLen(string1) >= strLen(string2) ? strLen(string1) : strLen(string2) (because not everybody has max() function in their library), otherwise, most of people here can't test your code!

Saying that, the matter here is not how to make "Is()" function more efficient anymore!
Here, we are also in disagreement. If the programmer is confronted with a real world task, then they are free to rearrange their code to achieve the highest efficiency that they can. There is more than one way to code, to achieve a solution. Ignoring that AutoHotkey can solve the problem differently, is arguably to be bias.

The "Is()" function examples demonstrate that, for the same amount of loop iterations, AHK lags behind Javascript ~= 19x time! (Suggesting that AHK loop is in fact really slow!)

Of course "Is()" function can be made more efficient in AHK by avoiding less loop iterations in many ways!
And why wouldn't an AutoHotkey programmer not use other viable solutions to increase performance or to solve their problem? If there are other ways for he or she to do it (within AutoHotkey), then why not use them? Keep in mind, that the person might only know AutoHotkey, they don't want to or don't have the time to invest learning another language to solve the problem at hand, or are perfectly happy with the performance they are getting from AutoHotkey.

Bypassing the use of loops for other code, separating the code into smaller pieces, or rearranging the code are arguably very viable options. Seems quite unfair for an advocate of another programming language to restrict working solutions from the AutoHotkey side, in order to confirm their bias against the language.
But there are a lot of situations where heavy loop iteration is a must and can't be avoided! (so in these situations, AHK is not recommended!)
Maybe, maybe not! A heavy loop iteration could possibly be avoided, by the AutoHotkey programmer rearranging their code or using other types of AutoHotkey code.

Your not recommending AutoHotkey has nothing to do with a real world solution, and appears more to do with bias, possibly trolling. AutoHotkey is excellent for many types of tasks or it's value can be considered relevant to those who like to use it, so it's not someone's place to impose their personal opinion and bias. Your choice or my choice, might not be best for another person.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 11:33

@SOTE:
His opinion is based on testing - he is going too far though which makes it seem like he is trolling.
He devised a simple test code and executed the code in the same way in both languages. Afterwards he measured the time both languages take for that code.
Based on his tests it's safe to assume that AutoHotkey is in fact a lot slower than javascript when it comes to the extraction of 2 specific character from 2 long strings then comparing the characters.
This means that the used features are slower in AutoHotkey. Any method that we use in AutoHotkey would potentially have the same effect in javascript probably giving javascript the same advantage over AHK in my code.

AutoHotkeys value certainly doesn't come from execution speed.

@jeeswg it's probably because AHK needs to parse {} stuff and it might also be less optimized duue to the fact that it does more
(greater specialization always results in less overhead and thus greater speed)

@User:
My code is written for the latest AHK version (maybe it will work a few versions earlier since I wont always use the newest features but yeah)
If you want to use my scripts update.
If you dont want to update don't use my scripts.

@Topic
There is no limit to how much you can optimize. You can always spend more time optimizing stuff to make it faster.
However you want to avoid having to optimize as much as possible as it often involves a lot of work and will limit the future growth of your code-base due to greater specialization.
It's pointless to spend 100 of hours of aligning and realligning 100s of files and moving and shifting variables and functions and trying to find the perfect MCode structure if you could do the same in 30 lines of another language.
You never have to use another language - but at some point it just makes sense to use another language.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 13:24

Here's some C++ code for a case-insensitive compare function, but I'm not sure how to handle wchar_t (replace with short?) and towupper (can we include) with TDM-GCC to make it into machine code.

Code: Select all

int customstrcmpi(wchar_t* str1, wchar_t* str2, int count)
{
	for (int i = 0; i < count; ++i)
	{
		//if (str1[i] != str2[i])
		if (towupper(str1[i]) != towupper(str2[i]))
		{
			count = i;
			break;
		}
	}
	return count;
}
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 13:41

this bench is without merit. js is jit compiled. the function will have been optimized away by the 100th iteration, after which point ure comparing the speed of an interpreted language vs that of a compiled one. good job.
User avatar
nnnik
Posts: 4500
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 14:54

@jeeswg you might be interested in this topic:
https://www.autohotkey.com/boards/viewtopic.php?f=7&t=32

@swagfag:
even if js is jit compiled it is not as fast as compiled languages. It is slower by a rather large margin.
Also the fact that it is faster is not as important as the information how much faster it is.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 15:13

- @nnnik: I've compiled before with TDM-GCC, i.e. joedf's script.
- In the tutorial, I didn't see any mention of include (a problem which user 'quantum' mentioned in another thread) or types (incompatibility between Visual Studio and TDM-GCC).
- A machine code function that uses the Winapi MessageBox function would be a good example.
- I did see what looks like a script for compiling via Visual Studio, is that what you had in mind?
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)

03 Feb 2019, 15:53

But you have to write too much.(Yes I'm lazy)
Actually you dont need this part: ,"int",1,"cdecl") We could create a caller function that does the thing we want.
In order to use the stdcall convention(Wich is the standard for the DllCall function) you have to put a _stdcall before the function.
Your C++ code will look like this:

Code: Select all

unsigned int MyFunction(unsigned int a,unsigned int b)
{
if (a>0)  
return MyFunction(a-1,b*a);
else
return b;
}

unsigned int _stdcall MyFunctionCaller(unsigned int a)
{
return MyFunction(a,1);
}
The result:

Code: Select all

MyFunction := MCode("2,x86:i0wkBItEJAiFyXQKjWQkAA+vwUl1+sM=,x64:hcl0Bw+v0f/JdfmLwsM=")
MyFunctionCaller := MCode("
(LTrim Join
2,x86:i0QkBIXAdA5QSFDoAAAAAIPECMIEALgBAAAAwgQA,x64:i9GFyXQH/8npAAAAALgBAAAAww==
)")
Msgbox % DllCall(MyFunctionCaller,"uint",3)
But the Messagebox is empty. :o
No we didn't make a mistake. The Problems name is MCode:
OK Lets imagine you have a AHK script, but you have to call every function by its position: (e.g. call Char nr. 144.).
This is where your function starts at Char 144.
Now lets imagine we put some new code in front of your function.
Your function will be moved backwards e.g. 20 Chars.
If you don't change the starting nr. of your function you wont be able to call it properly.
In Machine Code it is exactly like this:
A function is called by calling the start address of the function.
But the function is added after the AHK stuff.
That's why your function is calling something else. This leads to errors.
The compiler is able to tell you the starting address it expected:
(Note: Not for 64 bit PCs)

Code: Select all

/*
unsigned int MyFunction(unsigned int a,unsigned int b)
{
if (a>0)  
return MyFunction(a-1,b*a);
else
return b;
}

unsigned int MyFunctionaddress()
{
return (unsigned int)(&MyFunction);
}
*/
MyFunction := MCode("2,x86:i0wkBItEJAiFyXQKjWQkAA+vwUl1+sM=,x64:hcl0Bw+v0f/JdfmLwsM=")
MyFunctionaddress := MCode("2,x86:uAAAAADD,x64:SI0FAAAAAMM=")
Msgbox % "The expected Address of the function is :" DllCall(MyFunctionaddress)
Msgbox % "The actual address of the function is :" MyFunction
So you cant call functions in a normal way. :evil:
So what do we do now :?:
The answer is function pointers. :!:...:?:
Functionpointers are documented here:
http://www.cplusplus.com/doc/tutorial/pointers/
Please read through the site mentioned before reading further.


To call our function in MCode we have to give it the pointer to our function.

Code: Select all

unsigned int MyFunction(unsigned int a,unsigned int b)
{
if (a>0)  
return MyFunction(a-1,b*a);
else
return b;
}

unsigned int _stdcall MyFunctionCaller(unsigned int a,unsigned int(*MyFunction)(unsigned int,unsigned int) )
{
return (*MyFunction)(a,1);
}
Results in:

Code: Select all

MyFunction := MCode("2,x86:i0wkBItEJAiFyXQKjWQkAA+vwUl1+sM=,x64:hcl0Bw+v0f/JdfmLwsM=")
MyFunctionCaller := MCode("2,x86:i0QkBGoBUP9UJBCDxAjCCAA=,x64:SIvCugEAAABI/+A=")

When we call the new function we also have to add the Function pointer.

Code: Select all

MyFunction := MCode("2,x86:i0wkBItEJAiFyXQKjWQkAA+vwUl1+sM=,x64:hcl0Bw+v0f/JdfmLwsM=")
MyFunctionCaller := MCode("2,x86:i0QkBGoBUP9UJBCDxAjCCAA=,x64:SIvCugEAAABI/+A=")
Msgbox % DllCall(MyFunctionCaller,"uint", 3,"UPtr",MyFunction)
6 was expected and if you did everything right it should be the result.
Same thing applies to any function you need to call.
Recommends AHK Studio
User
Posts: 407
Joined: 26 Jun 2017, 08:12

Re: JavaScript vs AutoHotKey (Simple Speed Test)

03 Feb 2019, 22:03

SOTE wrote:
03 Feb 2019, 11:11
Hehe! You are the only troll trolling here anyway!

Who is here ignoring that AutoHotkey can solve problems differently?

Who said that other viable solutions to increase performance can't be used in AHK?

Fact: AHk loop is slow! (You argue this because you are a troll!)

loop is a practical solution for any language, but in AHK it is too slow in such a way that forces people to write complex\longer\unreadable codes in order to avoid it!

My friend, stop trolling ok?
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: JavaScript vs AutoHotKey (Simple Speed Test)

04 Feb 2019, 06:59

User wrote:
03 Feb 2019, 22:03
SOTE wrote:
03 Feb 2019, 11:11
Hehe! You are the only troll trolling here anyway!

Who is here ignoring that AutoHotkey can solve problems differently?

Who said that other viable solutions to increase performance can't be used in AHK?

Fact: AHk loop is slow! (You argue this because you are a troll!)

loop is a practical solution for any language, but in AHK it is too slow in such a way that forces people to write complex\longer\unreadable codes in order to avoid it!

My friend, stop trolling ok?
Since your original post, notice that a number of people have submitted code that addresses your non real world claims against AutoHotkey. The impression that you are giving is that you don't want nor care for an AutoHotkey solution, but rather stick with your bias and attempt to crap on the scripting language for personal enjoyment (thus troll).
I didn't test your code, but I think you should remove "Local" statement (because not everybody uses AHK 1.1.27+)
So people can't update their version of AutoHotkey? If a solution is to be found in a later version, unless that person has a good or particular reason for doing so, they are free to upgrade. The majority would likely upgrade, if it was going to actually solve their problem.
Saying that, the matter here is not how to make "Is()" function more efficient anymore!
This gives the impression that you don't want changes concerning the "Is()" function, because it will reduce the time difference or show AutoHotkey as being faster (which the other scripts are arguably doing).
Of course "Is()" function can be made more efficient in AHK by avoiding less loop iterations in many ways!
If the function can be made more efficient, and you are agreeing with such, then why wouldn't an AutoHotkey programmer not allow for the use of various options? It appears that you don't want the use of such options.
But there are a lot of situations where heavy loop iteration is a must and can't be avoided! (so in these situations, AHK is not recommended!)
This statement is debatably wrong. If there are other options besides a heavy loop iteration, then the AutoHotkey programmer should be free to choose such. It's not for you or me to impose on people what they should choose. As mentioned, they can use different coding methods, add machine code, or even put other programming/scripting languages into the script.

Lastly, it doesn't seem like you want a solution or would rather prevent others from thinking up workarounds that address this "made up problem" that isn't an actual project or problem.

Return to “Other Programming Languages”

Who is online

Users browsing this forum: No registered users and 27 guests