qwerty12 wrote: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.