Programs started with the AHK Run command are slow Topic is solved

[llinfeng]

Problem Statement
If I start the program "gvim.exe" through AHK using the following arguments, I get a SLOW Vim. It should take 5 seconds or so to open a single text file in the extreme case.

Code: Select all

run "C:\vim\vim80\gvim.exe", , max

However, if I simply run "C:\vim\vim80\gvim.exe" using the Windows Run Window (or the Windows Command Prompt), I get a FAST Vim.

Question
Is there a way to directly call the command-line to start the "gvim.exe" through AHK? It seems we need to avoid using the "run" command native to AHK.

So far, anything related with the AHK "run" command is getting me problem. I have tried to use the AHK "run" command to open a *.bat file, and neither did it help.

[Xtra]

Use ComSpec with the run command.

HTH

[llinfeng]

A tentative solution goes as follows. I am away from home and have not yet tested the performance.

Code: Select all

Run %comspec% /C gvim  +VimwikiMakeDiaryNote, , max

However, it is unclear to me why the native "Run" command for AHK should make things slower, in a systematic manner. (In may case, reading (using Vim) a single text-file with as few as one line in it should take 4~5 seconds. The lag is persistent regardless of how big the file is. More details in this post: https://github.com/vimwiki/vimwiki/issues/328).

@Xtra, thank you for pointing me to the right direction for solving the problem

[jeeswg]

Just in case it has something to do with 32-bit redirection:

Code: Select all

if A_Is64bitOS
	DllCall("kernel32\Wow64DisableWow64FsRedirection", PtrP,0)

[llinfeng]

Problem with the "tentative solution"

Code: Select all

    Run %comspec% /C gvim  +VimwikiMakeDiaryNote, , max

1. Simply, it does not work; "gvim.exe" session started in this manner is still SLOW.
2. Additionally, the ", max" option stops to work. I might have used the syntax wrong.

@jeeswg, could you please be more precise about where I should drop the two lines you suggested? The mapping that I am debugging goes as follows:

Code: Select all

#j::
IfWinExist, Wiki/Warehouse
    groupactivate, JOURNALS, r
else
	; The original SLOW version
	;run "C:\vim\vim80\gvim.exe", , max
	
	; The "modified" SLOW version (with problem to maximize the window).
	run %comspec% /C gvim  +VimwikiMakeDiaryNote, , max
return

Lastly, here goes the specification of all the programs involved:

• * Windows OS: 64-bit
  * AHK v1.1.24.00 (Unicode 32-bit)
  * Gvim.exe (MS-Windows 32-bit GUI version)

[Xtra]

You should have the full path to gvim in the comspec version.

[jeeswg]

@llinfeng
Put the 2 lines somewhere at the top of the script (the 'auto-execute section') before any hotkey labels, or, somewhere before the Run line. The idea is a bit of long shot, but there's a possibility it might work.

Btw you may remember me from that CapsLock on a remote PC problem, on Stack Overflow, hope that's going well, my name there starts with 'v', nice to see you here as well.

[qwerty12]

Is your AutoHotkey script started by the Task Scheduler (usually done to get an elevated instance of your script running at startup without a UAC prompt)? The Task Scheduler runs programs by default with below normal CPU priority and low I/O priority. When low, these settings get inherited by the process's children.

To check for this, start gVim from your AutoHotkey script and then use Process Explorer to determine gvim.exe's priorities.

Environment variables and the working directory also get inherited from the parent process; however, I don't believe the differences there (if any) would play a part in slowing down gVim. Nevertheless, you may try run "C:\vim\vim80\gvim.exe", %A_WinDir%\System32, max UseErrorLevel ; or C:\vim\vim80 to start gVim with a working directory explicitly set.

If you really can't work out why starting gVim from AutoHotkey causes it to slow down, then you could use Lexikos' ShellRun.ahk to run gVim. It requests a running Explorer.exe (the one displaying your desktop, I think) performs the duties of starting a program, so gVim will inherit Explorer's process priorities, token, environment, error mode, working directory, and a whole bunch of other stuff I don't know about. If the program supports it, ShellRun will allow you to launch a program maximised - look at the MSDN page linked in the code on GitHub and read up on the details for the Show parameter.

[llinfeng]

@llinfeng
Put the 2 lines somewhere at the top of the script (the 'auto-execute section') before any hotkey labels, or, somewhere before the Run line. The idea is a bit of long shot, but there's a possibility it might work.

Btw you may remember me from that CapsLock on a remote PC problem, on Stack Overflow, hope that's going well, my name there starts with 'v', nice to see you here as well.

Hi jeeswg, good to see you again! I have put the two lines right above the definition for the shortcut "#j", and things are still as slow as ****.

Here goes a link to the screencast demonstrating how *SLOW* things could get. This SLOW version of Vim is started using the following AHK script:

Code: Select all

    Run, %comspec% /C "gvim  +VimwikiMakeDiaryNote", , max

* Slow link: https://www.dropbox.com/s/s6ckaxwyje709 ... K.gif?dl=0

In contrast, here goes the demonstrating the *FAST* performance if I open the Gvim session from Run-Window (by hitting Win + R).
* Fast link: https://www.dropbox.com/s/ibyzi1fbjzwf8 ... n.gif?dl=0

[jeeswg]

Based on qwerty12's comments you could check the process priority in Task Manager.

Btw for the 32-bit redirection test, I would use run "C:\vim\vim80\gvim.exe", , max without ComSpec.

Also I would try run "C:\vim\vim80\gvim.exe" without Max, just in case.

Great gifs btw, that's quite a difference in speed, I like that animal thing, ASCII art.

[EDIT:] Btw you could create a lnk, and get AHK to run that.

[EDIT:] I would put the 2 lines above #j::, only if #j:: is the first hotkey label in the script. Btw one other idea is to try running the script via AHK x64. The only other thing I can think of at the moment, is ShellExecuteEx v. CreateProcess.

[llinfeng]

Is your AutoHotkey script started by the Task Scheduler (usually done to get an elevated instance of your script running at startup without a UAC prompt)? The Task Scheduler runs programs by default with below normal CPU priority and low I/O priority. When low, these settings get inherited by the process's children.

To check for this, start gVim from your AutoHotkey script and then use Process Explorer to determine gvim.exe's priorities.

Environment variables and the working directory also get inherited from the parent process; however, I don't believe the differences there (if any) would play a part in slowing down gVim. Nevertheless, you may try run "C:\vim\vim80\gvim.exe", %A_WinDir%\System32, max UseErrorLevel ; or C:\vim\vim80 to start gVim with a working directory explicitly set.

If you really can't work out why starting gVim from AutoHotkey causes it to slow down, then you could use Lexikos' ShellRun.ahk to run gVim. It requests a running Explorer.exe (the one displaying your desktop, I think) performs the duties of starting a program, so gVim will inherit Explorer's process priorities, token, environment, error mode, working directory, and a whole bunch of other stuff I don't know about. If the program supports it, ShellRun will allow you to launch a program maximised - look at the MSDN page linked in the code on GitHub and read up on the details for the Show parameter.

Hi @qwerty12,

Indeed, I have scheduled the AHK script to run when I log on to the machine; yet, this does not appear to make a difference. The Vim started through the following AHK script/clause/snippet is identically slow:
* If I run the scheduled task for my ahk_script.ahk
* If I run the ahk_script.ahk file all by itself (by going to its File Explorer location)
* If I run the ahk_script.ahk through a shortcut, using the Windows Run Window.

Code: Select all

    ; The script that I used
    Run, %comspec% /C "gvim  +VimwikiMakeDiaryNote", , max

Secondly, with regard to the priority issue, I have checked and make sure the following. However, gvim.exe started through AHK remains to be slow.
1. The gvim.exe process is in the always in the Real-time (highest) Priority class
2. Nothing is inhibiting the gvim.exe process to use all the cores of the CPU
3. The gvim.exe process has the highest possible I/O priority
4. The AutoHotKey.exe[32] process also has highest possible Priority class and I/O priority

* The difference in performance of the two processes (SLOW and FAST VIM)
When doing the same file operation (opening a diary file), the only difference I can read from the process info is that: for the SLOW Vim started through AHK, the surge in I/O Delta is lagged, and high, and persistent for a longer time. For the FAST Vim started from the Windows Run Window, the surge in I/O Delta is abrupt (within a second), and vanishes quickly.

[llinfeng]

Is your AutoHotkey script started by the Task Scheduler (usually done to get an elevated instance of your script running at startup without a UAC prompt)? The Task Scheduler runs programs by default with below normal CPU priority and low I/O priority. When low, these settings get inherited by the process's children.

To check for this, start gVim from your AutoHotkey script and then use Process Explorer to determine gvim.exe's priorities.

Environment variables and the working directory also get inherited from the parent process; however, I don't believe the differences there (if any) would play a part in slowing down gVim. Nevertheless, you may try run "C:\vim\vim80\gvim.exe", %A_WinDir%\System32, max UseErrorLevel ; or C:\vim\vim80 to start gVim with a working directory explicitly set.

If you really can't work out why starting gVim from AutoHotkey causes it to slow down, then you could use Lexikos' ShellRun.ahk to run gVim. It requests a running Explorer.exe (the one displaying your desktop, I think) performs the duties of starting a program, so gVim will inherit Explorer's process priorities, token, environment, error mode, working directory, and a whole bunch of other stuff I don't know about. If the program supports it, ShellRun will allow you to launch a program maximised - look at the MSDN page linked in the code on GitHub and read up on the details for the Show parameter.

It seems like things are *really* not working out, and I have tried Lexikos' ShellRun.ahk script. It worked well! In combination with a *.bat file, I can even supply command-line parameters to the function-call for ShellRun!

Remaining Questions
1. [Semi-major] It seems that I cannot supply a "maximize" parameter to the ShellRun function call.
2. [minor] When I run the ShellRun command, the *focus* of the Window may or may not get switched to the new window. Maybe this is out of the scope of this post, but can I fix this "focus" issue in an elegant way?

Code: Select all

; The current working version that does not maximize, with dummy method to regain focus to the new window.
#j::
IfWinExist, Wiki/Warehouse
    groupactivate, JOURNALS, r
else
    ShellRun("c:\users\llinfeng\Nutstore\DotFile_Private\bat_file\vim_start_diary.bat")
    sleep 3000
    groupactivate, JOURNALS, r
return

[llinfeng]

Based on qwerty12's comments you could check the process priority in Task Manager.

Btw for the 32-bit redirection test, I would use run "C:\vim\vim80\gvim.exe", , max without ComSpec.

Also I would try run "C:\vim\vim80\gvim.exe" without Max, just in case.

Great gifs btw, that's quite a difference in speed, I like that animal thing, ASCII art.

[EDIT:] Btw you could create a lnk, and get AHK to run that.

[EDIT:] I would put the 2 lines above #j::, only if #j:: is the first hotkey label in the script. Btw one other idea is to try running the script via AHK x64. The only other thing I can think of at the moment, is ShellExecuteEx v. CreateProcess.

@jeeswg, it appears to be the case that something more tricky than priority level is happening behind the scene; yet, ShellRun from Lexikos does COMPLETELY solve my SLOW VIM problem.

Now, what's left to do is some more touch work to make sure things are working as they were in the *old days*, where:
1. I am starting a MAXimized window when I start the new session of vim;
2. That the new session gain focus every time.

In complement to your idea for using "lnk", *.bat files will also do a pretty good job.

PS: the ASCII art is created by a Vim plugin called Startify. It should even get you a new quote every time you start a new Vim session.

[qwerty12]

Hi llinfeng,

Indeed, I have scheduled the AHK script to run when I log on to the machine; yet, this does not appear to make a difference. The Vim started through the following AHK script/clause/snippet is identically slow[...]

Secondly, with regard to the priority issue, I have checked and make sure the following. However, gvim.exe started through AHK remains to be slow.[...]

If the priorities are the same, then I have no idea what could be causing the difference in speed, sadly. (Best of luck in finding an answer! I'm sorry that all I can offer is a workaround...)

1. [Semi-major] It seems that I cannot supply a "maximize" parameter to the ShellRun function call.

The most important part would be specifying 3 as the last argument to the ShellRun function, but I think you should ditch the batch file and start gVim directly:
ShellRun("C:\vim\vim80\gvim.exe", "+VimwikiMakeDiaryNote", "", "", 3)

2. [minor] When I run the ShellRun command, the *focus* of the Window may or may not get switched to the new window. Maybe this is out of the scope of this post, but can I fix this "focus" issue in an elegant way?

Not having gVim installed myself, and for lack of any better ideas, I would suggest something like this after the ShellRun command:

Code: Select all

WinWait, ahk_exe gvim.exe, , 3 ; you'll probably want to include a more specific WinTitle to match against
if (!ErrorLevel) ; WinWait did find a gVim window
	WinActivate

[llinfeng]

Hi llinfeng,

Indeed, I have scheduled the AHK script to run when I log on to the machine; yet, this does not appear to make a difference. The Vim started through the following AHK script/clause/snippet is identically slow[...]

Secondly, with regard to the priority issue, I have checked and make sure the following. However, gvim.exe started through AHK remains to be slow.[...]

If the priorities are the same, then I have no idea what could be causing the difference in speed, sadly. (Best of luck in finding an answer! I'm sorry that all I can offer is a workaround...)

1. [Semi-major] It seems that I cannot supply a "maximize" parameter to the ShellRun function call.

The most important part would be specifying 3 as the last argument to the ShellRun function, but I think you should ditch the batch file and start gVim directly:
ShellRun("C:\vim\vim80\gvim.exe", "+VimwikiMakeDiaryNote", "", "", 3)

2. [minor] When I run the ShellRun command, the *focus* of the Window may or may not get switched to the new window. Maybe this is out of the scope of this post, but can I fix this "focus" issue in an elegant way?

Not having gVim installed myself, and for lack of any better ideas, I would suggest something like this after the ShellRun command:

Code: Select all

WinWait, ahk_exe gvim.exe, , 3 ; you'll probably want to include a more specific WinTitle to match against
if (!ErrorLevel) ; WinWait did find a gVim window
	WinActivate

Thanks a lot! My Vim is back alive again! Things are working out like a breeze!!!!! Many thanks to everyone in this thread