Best approaches for using Sharepoint Object Models

Approach-1:
Though garbage collector automatically releases memory allocated to unused objects, but it will release in a unpredictable manner. The .NET Framework provides the IDisposable interface, which exposes a Dispose method that you should call to explicitly release these unmanaged resources. 
To invoke Disnpose method, you can use the using keyword, you can use the try/finally code block or you can explicitly invoke Dispose method. Example of using keyword:

using (SPSite site = new SPSite("URL of the Site Collection"))
{
// Code here
}

Internally the compiler converts the using block to try/finally block as shown below.
SPSite site = null;
try
{
site = new SPSite("URL of the Site Collection");
// Code here
}
finally
{
if (site != null)
site.Dispose();
}

The SPSite and SPWeb types both implement the IDisposable interface, and both allocate unmanaged memory. If you do not correctly release SPSite and SPWeb instances, you will probably experience memory leaks, crashes, and frequent application pool recycles.
But if they are derived from the context object then the framework will take care of releasing resources, you should not release the resources.

·         SPContext.Current.Web

·         SPContext.Current.Site

·         SPContext.Current.Site.RootWeb

For example SPWeb web = new SPSite(SPContext.Current.Web.Url).OpenWeb().
Here the web object is derived from the SPContext, so we should not dispose that. Here SPWeb object web.Dispose() automatically called. Read this tutorial Disposing SharePoint Objects

Approach-2:

SPDisposeCheck is a tool that analyzes the custom SharePoint solution that uses SharePoint object model. If you can using SPSite or SPWeb objects then it is very much necessary to dispose the objects. Many SharePoint API's allocate COM based memory that is not released by CLR garbage collection and must be released by calling the Dispose() methods. As the name suggests SPDisposeCheck will check your assemblies and will let you know the memory leaks according to the Microsoft standards. It is a command line utility and called by the Visual studio addin. It takes path to a managed .DLL or .EXE or the path to a directory containing many managed assemblies. Then it starts analyzing the memory leaks.

You can download the from the below URL
http://code.msdn.microsoft.com/SPDisposeCheck
After downloading this and during installation you can tick on the check boxes to integrate SPDisposeCheck to visual studio 2010.
Once the Integration happens it can be found under Tools -> SharePoint Dispose Check in Visual Studio. Read this tutorial for more on SPDisposeCheck for SharePoint 2010

Approach-3:

SPQuery: If you are using SPQuery object to retrieve data from a large list then you should give a RowLimit else it perform poorly and will fail on large lists. So give RowLimit between 1 and 2000.
Also you should limit the result set in threshold in Microsoft SharePoint Foundation 2010, which is by default 5000 items.

Approach-4:

While deploying code using wsp solutions, ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment.
Approach-5:

Use the new SharePoint 2010 feature Developer Dashboard for viewing SharePoint page performance.

Approach-6:

If you are working with event receiver then Do not instantiate an SPWeb, SPSite, SPList, or SPListItem object within an event receiver. Because it creates sometimes Significant additional roundtrips to the database and Calls to the Update method on these instances can cause subsequent Update calls in other registered event receivers to fails.
For example follow like below:
So instead of writing like
using (SPSite site = new SPSite(properties.WebUrl))
use like below:
SPWeb web = properties.OpenWeb();
SPListItem item = properties.ListItem;

Ensure these things during development…!