Have a look at the following code segment:

while(true)
{
    using (SPSite siteCollection =
        new SPSite("http://localhost"))
    using (SPWeb site =
        siteCollection.OpenWeb("/Marketing"))
    {
        SPFolder pagesFolder = site.GetFolder("Pages");
        foreach (SPFile page in pagesFolder.Files)
        {
            WL(page.Url);
            using (SPLimitedWebPartManager webPartManager =
                page.GetLimitedWebPartManager
                    (PersonalizationScope.Shared))
            {
            }
        }
    }
}

With this code segment I'm just connecting to a site and iterating over the page collection, grabbing and instance of the page's SPLimitedWebPartManager as I go. Since SPLimitedWebPartManager implements the IDisposable pattern I am being a good citizen and wrapping its instantiation in a using {} block. The problem with this code segment is that this is what it does to the process memory:

image

Now, if I change the source code to this:

while(true)
{
    using (SPSite siteCollection =
        new SPSite("http://localhost"))
    using (SPWeb site =
        siteCollection.OpenWeb("/Marketing"))
    {
        SPFolder pagesFolder = site.GetFolder("Pages");
        foreach (SPFile page in pagesFolder.Files)
        {
            WL(page.Url);
            using (SPLimitedWebPartManager webPartManager =
                page.GetLimitedWebPartManager
                    (PersonalizationScope.Shared))
            {
                webPartManager.Web.Dispose();
            }
        }
    }
}

The memory picture looks much different now:

Sorry, somehow through several blog migrations this one image has been lost. Pretend this is a memory graph showing that the memory actually does not keep growing but instead actually releases back to 0.

The only difference being the addition of an explicit Dispose() within the webPartManager using.

A look inside the SPFile.GetLimitedWebPartManager call reveals that it calls an internal GetLimitedWebPartManagerInternal() method on the SPFile SPWeb member variable. A closer look at this method shows the following code:

SPWeb web = this.Site.OpenWeb();
if (this.AllowUnsafeUpdates)
{
    web.AllowUnsafeUpdates = this.AllowUnsafeUpdates;
}
SPWebPartManager manager = web.GetWebPartManagerInternal(pageUrl, requestedView, forRender, includeHidden, out bytes);

We see here that a new SPWeb object is getting spun up, and in the call to GetWebPartManagerInternal an assignment is going to be made to the SPLimitedWebPartManager m_web member variable. If we look at the Dispose() implementation for SPLimitedWebPartManager, we see the following:

public void Dispose()
{
    if (!this.m_disposed)
    {
        if (this.m_manager != null)
        {
            this.m_manager.Dispose();
        }
    }
    else
    {
        return;
    }
    this.m_webParts = null;
    this.m_manager = null;
    this.m_disposed = true;
}

Nothing is being done to dispose of the m_web! If I explicitly dispose of m_web, then memory stays low.

Is anyone encountering the same?