|
 |
|
31 Mar 2013
|
#11
|
|

Quote: Originally Posted by nilank
1. Disablepagingexecutive: Changing this value to 1 "forces" Windows to keep the kernel in RAM and not page it to the pagefile. Pretty useless. Windows 7 is quite smart on this part. It keeps the kernel in RAM whenever possible automatically, no need to tweak -- and it's always there in the memory if you have plenty of it (4 gigs and above).
Actually not useless if you're debugging on x64, if you want to get callstacks with most debugging tools. Also, it keeps the kernel *executive* - drivers and system code that could normally be paged out - in memory. It's not quite the same as the whole kernel.
It does have dangers though - if the kernel executive is locked in memory and you have a system with heavy memory pressure, not being able to page this portion of the kernel out could result in a bugcheck, so you should only enable this when debugging. Not useless, but could be dangerous and only for use under specific scenarios. Also, memory pages that make up the kernel executive aren't likely to be paged out unless some of those pages go inactive for long periods, or there's memory pressure - this really isn't going to get you much of a performance benefit anyway.

Quote: Originally Posted by nilank
2. Largesystemcache: Changing this value is known to bog/slow the system down. This tweak only helps in server environments, not for general users like us.
That depends - if the main use of the system is to load a lot of files (or fewer large files) into memory and manipulate them, this would definitely have a benefit in that specific scenario. That's not a common desktop scenario, but for those people doing development of large VS projects, or perhaps CAD or manufacturing work, this can actually benefit if the files that are loaded would continuously be accessed or reloaded over and over. It's specific, but it has it's uses. It is true this is more beneficial in a file server capacity on a server though.
As to the rest:
- NonPagedPoolQuota
This setting overrides the default dynamic value that any one process or driver can call to allocate from the kernel's nonpaged pool memory pool, and replaces it with a value (and the maximum size that can be set for max allocation differs between 32 and 64bit OSes). Given this is designed more for troubleshooting, or systems where nonpaged pool exhaustion may happen if not controlled (I've not ever in my life seen an x64 desktop come close to causing this before other issues occur as well, for what it's worth), it doesn't give you *any* performance gains by setting it. Also, because you're taking over for the memory manager when setting this, you should be *very* sure you're not causing issues by removing the dynamic nature of the nonpaged pool controls on Vista/2008 or higher systems....
- NonPagedPoolSize
Similar to the previous value, this setting is for configuring the maximum size of the kernel nonpaged pool that is allocated (in bytes, I believe) versus letting it be sized based on available RAM in the system during boot. I would argue that setting this outside of XP/2003 is no longer necessary (because the pools can dynamically grow or shrink based on system load), and setting it has no performance improvement implications either (just like the previous setting).
- PagedPoolQuota
See nonpagedpoolquota - this setting does the exact same, but for the kernel paged pool memory pool. As with setting a nonpagedpoolqouta value, it's really for tshooting or for systems where you already know and are trying to control paged pool memory resources. As with Vista/2008 and higher, given nonpaged pool and paged pool sizes can dynamically grow or shrink in the kernel memory region as necessary, this really is a relic of old thinking and old system designs and isn't necessary. Also, just like nonpagedpoolquota, there aren't performance implications with setting this either.
- PagedPoolSize
See nonpagedpoolsize.
- SessionViewSize
Setting this value to a value higher than the default allows for more memory to be allocated for desktop heap usage, but I would argue if you're running out of desktop heap you either have a poorly written application, or you already know what to set this size to (as determined by the application vendor who knows this is already going to be a problem). Again, there aren't performance benefits to setting this, but you could be reducing the amount of memory used in other kernel pool areas relating to the desktop and services - this isn't one you should play with unless you have good reason to, and the reasons would *not* be performance-related.
- SessionPoolSize
This memory is reserved for video driver allocations for drawing items on the desktop, and on 64bit systems the default for this value is already 64MB. As with setting the SessionViewSize, if you need to configure this it would be for a specific application that uses the GPU directly and would need more than the default 64MB for drawing items in an application on the desktop. Very specific setting, and does not affect performance (but may be required for specific applications that use the GPU directly to draw items on the desktop, usually within an app - I ran across a CAD app once that wanted 128MB here, but that was once in about 20 years).
- WriteWatch
This registry value died with Windows 2000 and hasn't been used since then (if you set it, it does nothing on XP/2003 and higher).
|
My System Specs |
|
Computer type PC/Desktop
System Manufacturer/Model Number Custom
OS Windows 10 Pro x64
CPU Intel Core i7 4790K @ 4.5GHz
Motherboard Asus Maximus Hero VII
Memory 32GB DDR3
Graphics Card Nvidia GeForce GTX970
Sound Card Realtek HD Audio
Screen Resolution 1920x1200
PSU Corsair AX760i
Case Fractal Design Define R4
Cooling Noctua NH-D15
Hard Drives 1x Samsung 250GB SSD
4x WD RE 2TB (RAIDZ)
31 Mar 2013
|
#12
|
|

Quote: Originally Posted by cluberti

Quote: Originally Posted by nilank
1. Disablepagingexecutive: Changing this value to 1 "forces" Windows to keep the kernel in RAM and not page it to the pagefile. Pretty useless. Windows 7 is quite smart on this part. It keeps the kernel in RAM whenever possible automatically, no need to tweak -- and it's always there in the memory if you have plenty of it (4 gigs and above).
Actually not useless if you're debugging on x64, if you want to get callstacks with most debugging tools. Also, it keeps the kernel *executive* - drivers and system code that could normally be paged out - in memory. It's not quite the same as the whole kernel.
It does have dangers though - if the kernel executive is locked in memory and you have a system with heavy memory pressure, not being able to page this portion of the kernel out could result in a bugcheck, so you should only enable this when debugging. Not useless, but could be dangerous and only for use under specific scenarios. Also, memory pages that make up the kernel executive aren't likely to be paged out unless some of those pages go inactive for long periods, or there's memory pressure - this really isn't going to get you much of a performance benefit anyway.

Quote: Originally Posted by nilank
2. Largesystemcache: Changing this value is known to bog/slow the system down. This tweak only helps in server environments, not for general users like us.
That depends - if the main use of the system is to load a lot of files (or fewer large files) into memory and manipulate them, this would definitely have a benefit in that specific scenario. That's not a common desktop scenario, but for those people doing development of large VS projects, or perhaps CAD or manufacturing work, this can actually benefit if the files that are loaded would continuously be accessed or reloaded over and over. It's specific, but it has it's uses. It is true this is more beneficial in a file server capacity on a server though.
As to the rest:
- NonPagedPoolQuota
This setting overrides the default dynamic value that any one process or driver can call to allocate from the kernel's nonpaged pool memory pool, and replaces it with a value (and the maximum size that can be set for max allocation differs between 32 and 64bit OSes). Given this is designed more for troubleshooting, or systems where nonpaged pool exhaustion may happen if not controlled (I've not ever in my life seen an x64 desktop come close to causing this before other issues occur as well, for what it's worth), it doesn't give you *any* performance gains by setting it. Also, because you're taking over for the memory manager when setting this, you should be *very* sure you're not causing issues by removing the dynamic nature of the nonpaged pool controls on Vista/2008 or higher systems....
- NonPagedPoolSize
Similar to the previous value, this setting is for configuring the maximum size of the kernel nonpaged pool that is allocated (in bytes, I believe) versus letting it be sized based on available RAM in the system during boot. I would argue that setting this outside of XP/2003 is no longer necessary (because the pools can dynamically grow or shrink based on system load), and setting it has no performance improvement implications either (just like the previous setting).
- PagedPoolQuota
See nonpagedpoolquota - this setting does the exact same, but for the kernel paged pool memory pool. As with setting a nonpagedpoolqouta value, it's really for tshooting or for systems where you already know and are trying to control paged pool memory resources. As with Vista/2008 and higher, given nonpaged pool and paged pool sizes can dynamically grow or shrink in the kernel memory region as necessary, this really is a relic of old thinking and old system designs and isn't necessary. Also, just like nonpagedpoolquota, there aren't performance implications with setting this either.
- PagedPoolSize
See nonpagedpoolsize.
- SessionViewSize
Setting this value to a value higher than the default allows for more memory to be allocated for desktop heap usage, but I would argue if you're running out of desktop heap you either have a poorly written application, or you already know what to set this size to (as determined by the application vendor who knows this is already going to be a problem). Again, there aren't performance benefits to setting this, but you could be reducing the amount of memory used in other kernel pool areas relating to the desktop and services - this isn't one you should play with unless you have good reason to, and the reasons would *not* be performance-related.
- SessionPoolSize
This memory is reserved for video driver allocations for drawing items on the desktop, and on 64bit systems the default for this value is already 64MB. As with setting the SessionViewSize, if you need to configure this it would be for a specific application that uses the GPU directly and would need more than the default 64MB for drawing items in an application on the desktop. Very specific setting, and does not affect performance (but may be required for specific applications that use the GPU directly to draw items on the desktop, usually within an app - I ran across a CAD app once that wanted 128MB here, but that was once in about 20 years).
- WriteWatch
This registry value died with Windows 2000 and hasn't been used since then (if you set it, it does nothing on XP/2003 and higher).
Wow,
Great info. I always was looking for a sticky somewhere where all of these or any other tweaks had a description since I see so many out there with the tweak itself, but no actual description whether it's helpful or not. Either way thanks for the response!
|
My System Specs |
|
Computer type PC/Desktop
OS Microsoft Windows 7 Professional 64-bit SP1
CPU Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
Motherboard Dell Inc. 0K42JR
Memory 8.00 GB
Graphics Card NVIDIA NVS 3100M
Sound Card (1) NVIDIA High Definition Audio (2) IDT High Definition A
Monitor(s) Displays 1
Screen Resolution 1440 x 900 x 32 bits (4294967296 colors) @ 59 Hz
Hard Drives Samsung SSD 840 PRO Series ATA Device
31 Mar 2013
|
#13
|
|
Boy oh boy cluberti that is a lot of information great job finding all that.
Here is the tweak that works for me.
Install a lot of ram and a ssd and a quick i7 cpu.
Select Windows to handle all memory, page filing, ect.
If I messed with all that other stuff I surly would also be doing a clean install.
|
My System Specs |
|
Computer type PC/Desktop
System Manufacturer/Model Number Home made Desktop
OS Windows 10 Pro. 64/ version 1709 Windows 7 Pro/64
CPU Intel i7-6800K @ 4.3
Motherboard ASUS X-99 Deluxe II
Memory Corsair Platinum 16 gig @2400
Graphics Card EVGA GTX 1070 OC
Monitor(s) Displays Asus 27" LED LCD/VE278Q
Screen Resolution 1920-1080 or 1280-720 HDMI
Keyboard Das 4 Professional
Mouse Logitech M705/MX Anywhere 2-S
PSU EVGA Platium 1200W
Case Phanteks Luxe Tempered Glass 8 fans/ one radiator
Cooling XSPC/ Water Cooled CPU
Hard Drives INTEL SSD 730-240 Gb Sata 3.0/
Internet Speed 100 mbits
Antivirus Microsoft Security Essentials/ Malwarebytes Premium 3.0/ SAS
Browser I.E. 11 default/Firefox/ ISP Time Warner Cable/Spectrum
Other Info LG BluRay Burner/
Sound system-KLipsch-THX/
Icy Dock ssd Hot Swap bays.
31 Mar 2013
|
#14
|
|

Quote: Originally Posted by Layback Bear
Boy oh boy cluberti that is a lot of information great job finding all that.
Here is the tweak that works for me.
Install a lot of ram and a ssd and a quick i7 cpu.
Select Windows to handle all memory, page filing, ect.
If I messed with all that other stuff I surly would also be doing a clean install.
Yup. I felt worried that I was going to destroy my laptop when I added "control panel" to my context menu, I can't imagine if I was poking around things that didn't even sound like they exist lol
|
My System Specs |
|
Computer type PC/Desktop
OS Microsoft Windows 7 Professional 64-bit SP1
CPU Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
Motherboard Dell Inc. 0K42JR
Memory 8.00 GB
Graphics Card NVIDIA NVS 3100M
Sound Card (1) NVIDIA High Definition Audio (2) IDT High Definition A
Monitor(s) Displays 1
Screen Resolution 1440 x 900 x 32 bits (4294967296 colors) @ 59 Hz
Hard Drives Samsung SSD 840 PRO Series ATA Device
31 Mar 2013
|
#15
|
|
To be honest, once I played around with all those keys but changing them never speeded my system up. I had noted down all the default values so it wasn't a problem.
|
My System Specs |
|
01 Apr 2013
|
#16
|
|
Nothing wrong with playing with your own box, but there just aren't that many tweaks one can make to a win7 (or higher) box to improve performance, and those that exist are mostly non-registry-based changes.
|
My System Specs |
|
Computer type PC/Desktop
System Manufacturer/Model Number Custom
OS Windows 10 Pro x64
CPU Intel Core i7 4790K @ 4.5GHz
Motherboard Asus Maximus Hero VII
Memory 32GB DDR3
Graphics Card Nvidia GeForce GTX970
Sound Card Realtek HD Audio
Screen Resolution 1920x1200
PSU Corsair AX760i
Case Fractal Design Define R4
Cooling Noctua NH-D15
Hard Drives 1x Samsung 250GB SSD
4x WD RE 2TB (RAIDZ)
|
|