If you are using Windows 2000 or Windows XP: you should try this performance tweak.
When installing Windows sometimes your Level2 memory cache of your CPU isn’t recognized. The way the installation handles this is rather dumb: it just sets your cache to 0! So, all that high performance and expensive memory isn’t used at all. What a waste.
Fortunately we can do something about it with Regedit:
1. Start, Run, Regedit
2. Lookup hkey_local_machine\system\currentcontrolset\contro l\session manager\memory management.
3. Subkey secondleveldatacache should contain hex value 200 when you have 512 Kb L2 cache. For 1 Meg L2 cache just fill in the hex value of 400, etc.
4. Done! Probably you have increased CPU performance by 20 percent!
Recommendation: download this piece of freeware software to lookup the properties of your CPU (also L2 cache). URL: http://www.3dcenter.de/downloads/wcpuid.php
I found this snippet on another site, and it looks like it comes from the book I just bought about building frameworks from the guys that worked on the .net framework.
DO report execution failures by throwing exceptions.
CONSIDER terminating the process by calling System.Environment.FailFast (.NET 2.0) instead of throwing an exception, if your code reaches a situation where you consider it unsafe for further execution.
DO NOT use exceptions for the normal flow of control, if possible.
CONSIDER the performance implications of throwing exceptions.
DO document all exceptions thrown by publicly callable members because of a violation of the member contract and treat them as part of your contract.
DO NOT have public members that can either throw or not based on some option such as a bool parameter (.e.g., bool throwOnError)
DO NOT have public members that return exceptions as the return value or as an out parameter.
CONSIDER using exception builder methods.
DO NOT throw exceptions from exception filter blocks
AVOID explicitly throwing exceptions from finally blocks.
DO throw the most specific (the most derived) exception that makes sense.
DO NOT swallow errors by catching nonspecifc exceptions ( e.g., catch (Exception e) { } // swallowed whole!)
CONSIDER catching a specific exception when you understand why it was thrown in a given context and you can respond to the failure programmatically.
DO Clean up any side effects when throwing an exception. For example, if a Hashtable.Insert method throws an exception, the caller can assume that the specified item was not added to the Hashtable.
DO NOT derive all new exceptions directly from the base class SystemException. Inherit from SystemException only when creating new exceptions in System namespaces. Inherit from ApplicationException when creating new exceptions in other namespaces.
DO use the predefined exceptions types. Define new exception types only for programmatic scenarios.
DO NOT overcatch. Exceptions should often simply be allowed to propagate up the call stack.
DO prefer using an empty throw when catching and rethrowing an exception. This is the best way to preserve the exception call stack.
AVOID creating custom exception classes when there is already an exception type that’s “good enough”.
DO Design classes so that in the normal course of use an exception will never be thrown.
DO NOT return Error Codes!
