I think there's some performance issues with the NSIS System plugin and Windows Vista.
I really need Vista testers for this, but some XP machines are needed also as a baseline.
If you would like to help my testing, please download the zip file, and run each EXE. It should popup a dialog box in 10-20 seconds. During this time, could you open Task Manager and watch the CPU usage for the executable. Please report back the EXE you ran, the average CPU usage, and the time elapsed (from the dialog).
And would the Vista testers also say whether or not you have UAC on or off.
Thanks!!
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
XP Pro with SP2:
ProcessWaitTEST_admin.exe Time: 12 seconds CPU: 17
ProcessWaitTEST_user.exe Time: 12 seconds CPU: 19
The developer formerly known as ZGitRDun8705
Windows Vista Home Premium SP1 UAC on
user.exe = ~10/9%, time = 12
admin.exe = ~10/9%, time = 13
cowsay Moo
cowthink 'Dude, why are you staring at me.'
XP Home - SP2:
admin.exe - 10 secs, 5-6% CPU
user.exe - 10 secs, 5-6% CPU
Windows Vista Home Premium x32 SP1 UAC on
user.exe = from 5 trough 10, time = 11
admin.exe = from 6 trough 9, time = 11
Include Real Time Protection from Spyware Terminator annoying (as always) asking if I want to run the file and taking precious time to check the task manager...
If a packet hits a pocket on a socket on a port,
and the bus is interrupted as a very last resort,
and the address of the memory makes your floppy disk abort,
then the socket packet pocket has an error to report
On Windows XP Professional SP2
ProcessWaitTEST_admin.exe:
Time: 11 seconds
CPU: 5-6
ProcessWaitTEST_user.exe:
Time: 11 seconds
CPU: 5-6
Thanks everyone who tested so far!!
Could you please re-download and run the same tests one more time? I tweaked the loop down to 500ms. This first tests were at 250ms to get a high end.
I figured out what was causing issue on my end. If you don't include
RequestExecutionLevel(doesn't matter if it's user or admin) then CPU usage is over double (!!) in Vista. This is the problem I was seeing, so thanks again for sorting it. Just need to see how much better a 500ms loop is so I can decide on a default.That actually makes some sense, as without a
RequestExecutionLevel(Vista's cue that the app is Vista-ready) under UAC, the app runs in compatibility mode: writes to Program Files or HKLM are virtualized to point somewhere in %USERPROFILE% or HKCU, respectively (such writes would just fail with RequestExecutionLevel user in play). I'm sure other stuff is emulated, too.Try turning UAC off and testing without
RequestExecutionLevel. See if CPU usage goes down. If it does, then you have your answer.Nope, CPU usage is through the roof regardless of UAC (I have it turned off on my laptop). My only guess is that without that option explicitly set, then for each system call Vista has to decide what to do with it, before checking the status of UAC. Even though NSIS is recognized by Vista and given the appropriate rights (elevated to admin I believe), this decision making process must take a lot of computations. Setting that value, whether user or admin, takes the decision out of Vista's hands, saving a lot of CPU.
But you're right, you'd think turning off UAC would aleviate the problem. No such luck.
On Windows XP Professional SP2 - Test 2
ProcessWaitTEST_admin.exe:
Time: 10 seconds
CPU: 2-4
ProcessWaitTEST_user.exe:
Time: 10 seconds
CPU: 2-4
User: Usage 7 to 15 Elapsed Time 11
Admin: Usage 6 to 16 Elapsed Time 10
Vista HP SP1 UAC on
User and Admin both = [3-6%, 11]
cowsay Moo
cowthink 'Dude, why are you staring at me.'
Windows Vista Home Premium x32 SP1 UAC on
user.exe = 2-10%, time = 11
admin.exe = 4-5%, time = 10
As usual... Include Real Time Protection from Spyware Terminator annoying (as always) asking if I want to run the file and taking precious time to check the task manager...
If a packet hits a pocket on a socket on a port,
and the bus is interrupted as a very last resort,
and the address of the memory makes your floppy disk abort,
then the socket packet pocket has an error to report