Performance Issues/fps Lag? This May Help!

[Psycho83]

Here's the simple batch file I use to run Garrys Mod. It clears up some occasional lagginess/stuttering I get with steam.exe and windows being pushy for resources. This made a HUGE difference on my old Athlon X2 5000+ machine and the difference is still noticeable on my new i7 3770K. It'll make a big difference for folks with laptops and dated hardware with underpowered CPUs (all the physics makes Garrys Mod a very CPU intensive game)

What it does:

1. Kills Explorer.exe to free up processor time and memory.

2. Lowers the priority of steam.exe

3. Launches Garrys Mod and elevates its priority to high.

4. When you're done playing, hit space and it will reload your desktop for you.

 

 

taskkill /f /IM explorer.exe

steam.exe -applaunch 4000

wmic process where name="steam.exe" call setpriority 64

wmic process where name="hl2.exe" call setpriority 128

pause

wmic process where name="steam.exe" call setpriority 32

explorer.exe

exit

 

So you want to try it out?

1. Go to your Steam folder (should see steam.exe in there) and create a text file called Gmod.txt

2. Copy/past the stuff in the above quote box into your notepad window and click 'save as'.

3. Change the name to "Gmod.bat" and click save.

4. Right-click your new file and hit 'Copy. Now right-click your desktop and hit 'Paste Shortcut'

5. (Optional) To give it a pretty icon; right-click your new shortcut and go to 'Properties'. Click 'change icon'. Paste this in the box at the top and hit okay:

%ProgramFiles% (x86)\Steam\SteamApps\common\GarrysMod\garrysmod\resource\game.ico

If you installed steam to some weird directory, just search around until you find garrysmod\resource\game.ico and select it.

 

Just double-click it just like you would the standard game icon.

Lemme know if it helps you!

 

Worried I'm some script-kiddie looking to take over your computer? This is a simple batch file; every command is plain to see and can easily be checked in google. I'll gladly take a ban if any of this batch file is malicious in any way. It's not.

[Math]

Or you could buy a new computer?

[Short]

Or you could buy a new computer?

 

Yea... i don't really see how this would help at all unless you run a 512mb toaster...

Edited September 19, 2013 by Short

[Quadcore]

Yea... i don't really see how this would help at all unless you run a 512mb toaster...

 

could always overclock

http://www.youtube.com/watch?v=Gw-rUCwLoQ0[/url]

Edited September 19, 2013 by Quadcore

[Arezk]

hahahah you guys just so funny.

[Psycho83]

Yea... i don't really see how this would help at all unless you run a 512mb toaster...

Lol... My Athlon X2 rig had 4 gigs of ram. Doesn't matter..

It's about processor time. If something other than hl2.exe grabs cycles on your processor, the physics engine has to wait and you get an FPS stutter. Altering the priorities and eliminating explorer.exe helps avoid this.

CPU bottleneck was the only thing I claimed this would help with.

Also, since intel and AMD are going for more cores instead of higher clock rate (and physics threads notoriously don't like multi-threading), even machines with modern CPUs will show an improvement with this.

 

could always overclock

Hahah.. yeap. My i7 is running at 4.2 Ghz at the moment. Sexy beast this thing is.

Edited September 20, 2013 by Psycho83

[enigma#]

taskkill /f /IM explorer.exe

steam.exe -applaunch 4000

wmic process where name="steam.exe" call setpriority 64

wmic process where name="hl2.exe" call setpriority 128

pause

wmic process where name="steam.exe" call setpriority 32

explorer.exe

exit

 

I'm going to break down your script so it's understandable to the average user and the implications.

 

Line 1: killing off explorer FORCIBLY via the name of Windows Explorer's shell. This is 'explorer.exe'.

Line 2: Telling Steam to launch Gmod.exe (app id of Gmod is 4000) - there is an extensive guide on what APP IDs correspond to what games.

Line 3: Tells WMI (it's a way to tell Windows to do something very specific or grab a set of specific ionformation) to change the priority (as in how important it is relative to other running applications) of 'steam.exe' (steam's main program) to 'low'. This means most programs will take precedence in processor time OVER steam.exe

Line 4: Tells WMI to change the priority of any application with an image name of HL2.exe to set the priority of 'realtime'.

Line 5: Tells your script to wait for someone to do something (typically space bar or enter will cause the script to go)

Line 6: tells WMI to change the priority of 'steam.exe' to go back to 'normal'. Effectively reverts what Line 3 did.

Line 7: launches the Windows Explorer shell.

Line 8: quits the script

 

So while this script seems innocuous, it has some implications that people should be aware of.

 

in Windows 7, the scheduler process handles things differently than in Windows XP.

So assuming we're in Windows 7 world:

 

From a very simplistic standpoint, it is advantageous to elevate the priority of HL2.exe when playing on a computer with less performance.

It may affect negatively OTHER system priority tasks since you are basically saying it's more important than background tasks. While most users won't notice it, it has implications on the scheduling on I/O devices such as keyboards, mice... Granted your computer isn't fast enough to handle HL2.exe effective since it competes with other resources like (graphics drivers, other background applications like web browsers), giving it ELEVATED priority over crucial resources like your mouse and keyboard MAY negatively your experience. However, it honestly depends on program itself. By saying: I'm giving HL2.exe real-time priority... you're saying that IF Garry's Mod wants to chew up every processor cycle... it can. This can effetively hang your compouter should something like windows update or a background process requiring a substantial amount of CPU time pops up. The reason why this happens is that when you have TWO real-time priority tasks, they WILL CLASH. Whoever needs more, WILL WIN.

I WOULD highly recommend you NOT set anything to realtime unless Windows scheduler actually does it.

 

For more information, consult this article: http://msdn.microsoft.com/en-us/library/ms685100%28VS.85%29.aspx

 

Building on Windows 7, it uses something called SuperFetch. SuperFetch is a PRESUMPTIVE loader of files and applications based on your I/O habits. So things like opening HL2.exe on a consistent basis will cause SuperFetch to PRELOAD many of the resources related to HL2.exe to be preloaded to ensure that you can launch it quickly. This is in effect a smarter way to force Windows to preload your game files more often. That being said, setting HL2.exe to high may cause some benefits to be observed in older systems.

 

Here I use RAMMap to show you what SuperFetch does in Windows 7:

 

If you look at the files loaded here, you'll notice there are a few things related to the games I play... like Battlefield 3, PayDay 2, Dishonored, World of Warcraft, League of Legends and even things related to what I do on the web like the Flash plugin.

 

My point is.. what he is suggesting is a bandadge fix and not a true fix to your problems related to your computer not performing well (As well illustrated by the replies).

 

Please use his script with caution if you have an older computer as well. It doesn't mean it's bad or it will break your computer but be aware of the consequences of what it does and what it can do.

[Psycho83]

By saying: I'm giving HL2.exe real-time priority...

Line 4: Tells WMI to change the priority of any application with an image name of HL2.exe to set the priority of 'realtime'.

This script does not set 'real-time' priority for anything. 256 is the setting for real-time. This script uses 128 which is simply 'High' priority. I would also recommend against setting anything to real-time.

Description of wmic setpriority options at microsoft.com for reference: http://msdn.microsof...7(v=vs.85).aspx

 

It may affect negatively OTHER system priority tasks since you are basically saying it's more important than background tasks.

This is only the case with heavily multi-threaded applications (which garrys mod is NOT) or on single-core processors which haven't been made since what, the Pentium 4 line? Other tasks still execute just fine with this launcher. This simply gives hl2.exe "dibbs" on processor cycles when it needs them (i.e. for smooth physics simulation of thousands of props and bouncing zombie gibs).

 

Building on Windows 7, it uses something called SuperFetch.

SuperFetch loads files into memory preemptively. It's totally unrelated to the scope of this launcher. SuperFetch allows the game to launch faster but has no effect what-so-ever on the in-game performance once everything is loaded and running.

My launcher mitigates physics-related stutter and that's all I've ever claimed it would do. If you're having load-time issues, get an SDD. I use a little SanDisk 64gig solid state drive for steam and other games and it's amazing.

 

All I can say is that it's made a big difference for me on multiple machines. I'm ranked 2nd place in over-all score on the HG ZombieSurvival server thanks, in part, to the smooth performance from this launcher. Figured I'd be a nice guy and share my trick.. I had no idea it would erupt into such a fiasco.

Edited September 20, 2013 by Psycho83

[enigma#]

128 is high priority (the priority my script sets for hl2.exe). 256 is the setting for real-time. I would also recommend against setting anything to real-time.

http://msdn.microsof...7(v=vs.85).aspx

Must have misread the article that was talking about this particular set of priorities.

I stand corrected on that as the information provided by the below link was incorrect.

https://blogs.techne...Redirected=true

 

Conflicts with:

http://msdn.microsof...7(v=vs.85).aspx

http://www.visualbas...9486-print.aspx

http://technet.micro...y/ee176707.aspx

 

This is only the case with single-core processors which haven't been made in what, a decade?

This was said under the assumption you were talking about real-time prioritisation.

Under the 'high' prioritisation, it wouldn't impact even single core processors that much.

 

As well, I'm not a big fan of elevating processes due to a few things

1. By escalating the process priority, you are granting it higher priority than crucial system processes (Explorer.exe isn't really considered 'crucial' as you can replace the shell with another binary if you really wanted to). This can like I originally said impact negatively your system REGARDLESS if it is in 'HIGH' or 'REALTIME' . Task Manager for instance runs in High priority. That's how it is able to load if all other programs hung in Windows.

 

2. It would be better for most users to de-escalate the priority of Explorer.exe / Steam.exe etc...

Escalating thread priorities fucks with the system scheduler... which I mean let's not do that. BSOD... >_>

Point is: It would be wiser to let Windows' scheduler handle this rather than trying to control it yourself as you did not program Garry's mod or the Windows scheduler service.

 

It is briefly discussed here implicitly:

http://joeduffyblog....ce-set-manager/

 

This is an implication of what you're doing with your script regardless of what 'performance gains' you'll get out of it.

Edited September 20, 2013 by enigma#

[Psycho83]

I stand corrected on that as the information provided by the below link was incorrect.

Yeah, best to get it from the horses mouth whenever possible.

 

 

It would be wiser to let Windows' scheduler handle this rather than trying to control it yourself as you did not program Garry's mod or the Windows scheduler service.

So I shouldn't modify the engine in my car because I wasn't the designer? I shouldn't have surgery or take medicine because I wasn't in control of my own evolution? That seems silly.

I've been playing Garrys Mod since.. jeez, I dunno, 04? I found it on my first play-through of HL2 when I was googling for a way to spawn one of those cool saw blades..

I've been using Windows since the early 90s starting with 3.0. I'm pretty sure it's safe to do a little tweaking with two decades of experience under my belt, thank you.

Escalating thread priorities fucks with the system scheduler... which I mean let's not do that. BSOD... >_>

I've never once had a BSOD from elevating priorities. Bad capacitors, bad drivers, failing hardware sure, they'll cause BSODs all day long.. It's nothing short of fear-mongering to suggest that using high priority on a thread will cause a BSOD.. Shame on you.

 

Here's the deal; computers are stupid. Having a task full-screen (like a game) isn't enough to convince your computer that you'd like to focus resources on it. That's what elevated priorities are for and that's what this batch file does.

Edited September 20, 2013 by Psycho83

[enigma#]

I'm not saying something will happen or something will most likely happen. I'm telling people to be aware of the consequences of what your script does.

 

I have neither an intention of nullifying what you're saying nor the intention to attack what you're saying.

I'm not saying it's a bad thing or anything in fact. I'm merely analysing and educating people about what your script does and what potential consequences it has. Not everyone is so lucky to understand WMI and the power it has over the scheduler.

 

If you still don't agree or believe what I'm saying, I guess we will have to agree to disagree.

Frankly, it's just an analysis of what you're suggesting. Based off the analysis, I drew a conclusion. It's not anything personal...

To be fair, Windows has evolved thankfully over the years to handle multiple cores and threads more appropriately, which is a huge plus plus for all of us gamers, programmers etc.. (i guess consumer xD).

[Psycho83]

I'm telling people to be aware of the consequences of what your script does.

Are you?

You did a lengthy writeup on load times and SuperFetch (unrelated to the script) and on the perils of 'real-time' priority (which this script doesn't even use).

Priority-induced starvation of system threads seems to be your only relevant concern and it doesn't even apply here.

From microsoft:

Whatever its priority attribute, any thread in the system can be preempted when hardware interrupts and certain types of software interrupts occur.

The kernel-defined interrupt request level (IRQL) to which a particular interrupt vector is assigned on a given platform.

The kernel prioritizes hardware and software interrupts so that some kernel-mode code, including most drivers, runs at higher IRQLs, thereby making it have a higher scheduling priority than other threads in the system. The particular IRQL at which a piece of kernel-mode driver code executes is determined by the hardware priority of its underlying device.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff540600%28v=vs.85%29.aspx

 

Even at 100% load on a single-core cpus, system threads will still edge in and execute just fine. HL2.exe can even crash all it wants, in whatever ways it likes. At high priority, it is still lower in the food chain than "crucial system processes".

 

Was there some other consequence you're concerned about?

If you still don't agree or believe what I'm saying, I guess we will have to agree to disagree.

I'm sorry, the documentation (directly from Microsoft) just don't support what you're saying. I don't mean to be rude, just trying clarify.

[enigma#]

I think there is a bit of misunderstanding on it.

 

I wrote

Must have misread the article that was talking about this particular set of priorities.

I stand corrected on that as the information provided by the below link was incorrect.

https://blogs.techne...Redirected=true

 

Conflicts with:

http://msdn.microsof...7(v=vs.85).aspx

http://www.visualbas...9486-print.aspx

http://technet.micro...y/ee176707.aspx

That acknowledges that the information that I originally had was incorrected therefore redacting/negating what I said before

 

This was said under the assumption you were talking about real-time prioritisation.

Under the 'high' prioritisation, it wouldn't impact even single core processors that much.

 

Under the false assumption that it was REAL-TIME Priority... which I corrected from above.

I wrote "Under the 'high' prioritisation, it wouldn't impact even single core processors that much.". Which is in agreeance with you.

 

As well, I'm not a big fan of elevating processes due to a few things

1. By escalating the process priority, you are granting it higher priority than crucial system processes (Explorer.exe isn't really considered 'crucial' as you can replace the shell with another binary if you really wanted to). This can like I originally said impact negatively your system REGARDLESS if it is in 'HIGH' or 'REALTIME' . Task Manager for instance runs in High priority. That's how it is able to load if all other programs hung in Windows.

Not all system crucial processes are under an IRQ. That is what I'm saying. Most hardware drivers, yes in fact have an IRQ and they do share them at times.

It was fallacious to make a blanket statement like that.

However, I acknowledge and have acknowledged the fact that high isn't harmful necessarily.

I was just pointing out what a general thought that sometimes you don't need to escalate thread priorities for the sake of possibly higher performance.

 

I understand the anecdotal nature of why you think it is beneficial.

I do not disagree, once again... my intentions are only to point out what it implies not what it WILL do

.

2. It would be better for most users to de-escalate the priority of Explorer.exe / Steam.exe etc...

Escalating thread priorities fucks with the system scheduler... which I mean let's not do that. BSOD... >_>

Point is: It would be wiser to let Windows' scheduler handle this rather than trying to control it yourself as you did not program Garry's mod or the Windows scheduler service.

 

It is briefly discussed here implicitly:

http://joeduffyblog....ce-set-manager/

 

 

This is my personal opinion about it. I wasn't saying don't use escalated threads or anything like that.

In regards to the BSOD comment, it was more so a humourous poke at how Windows freaks out on IRQs that are not playing nicely with each other or end up clashing with one another.

 

In regards to the Windows scheduler and SuperFetch comment, I wrote it mostly to praise the improvement way Windows handles thread scheduling and something most people don't realise. I do have more confidence that the scheduling in user-mode is for the better of Windows since it is done 'virtually' and not through a presumptive means. As a technical user, I do not have qualms about changing the thread priorities however I personally disagree with it on what I said before. It is a personal opinion and I provided my thoughts behind it. If you wish to disagree/disprove it, then by all means do so like you have explained.

 

Are you?

You did a lengthy writeup on load times and SuperFetch (unrelated to the script) and on the perils of 'real-time' priority (which this script doesn't even use).

Why are bringing this back up. I acknowledge the fault here and corrected myself. I'm sorry you feel like as though anything I say further is an attack or even ad hominem but it's not. I have addressed my SuperFetch comment in the previous commentary.

 

Priority-induced starvation of system threads seems to be your only relevant concern and it doesn't even apply here.

From microsoft:

 

http://msdn.microsof...0(v=vs.85).aspx

Not all drivers are written in kernel-mode. Some stay in user-mode (see UMDF). That's what perhaps needs to be made more clear. As all drivers are not created equal, some are loaded at the user-mode level instead. Your link deals specifically with Kernel mode drivers, so while I agree that kernel mode drivers (and in turn many hardware peripherals) will not suffer from an escalation of thread priority. It can still happen in user mode)

 

In regards to priority-induced starvation, I agree that while it is not always relevant. It is still at times relevant to understand that given that not all drivers are in kernel mode, and that many applications sit outside Kernel-mode... it would be foolhardy to assume it will never happen.

It would be also foolhardy not explain what that actually means for the user.

 

Even at 100% load on a single-core cpus, system threads will still edge in and execute just fine. HL2.exe can even crash all it wants, in whatever ways it likes. At high priority, it is still lower in the food chain than "crucial system processes".

I understand that. I would not disagree with that. Any 'kernel-mode thread' will have priority over 'user-mode thread' (for lack of better explanation) regardless of whether you set it real-time, high, or normal. I've clarified what I meant by that in my second reply. Your linked site illustrated that clearly.

 

I'm sorry, the documentation (directly from Microsoft) just don't support what you're saying. I don't mean to be rude, just trying clarify.

I agree that in kernel mode... I would be incorrect. However, we also work with user mode. Remember that they would not have priority explicitly over kernel mode if it wanted to.

I'm not here to negate or dismember what you say. I'm merely trying to explain my reasoning behind it.

Like any opinion, you are welcome to disagree.

Edited September 20, 2013 by enigma#

[Bioblade]

thanks for the script, but it still wont stop the random crashes to desktop when im playing....it always seems to happen after i buy expensive weapons

[Gamma.CM]

Ingenious. You have my gratitude.