Windows 7: Master File Table Size?

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.

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!

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

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.

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.