Re: StringBuilder Extension: IsQuotedBy

Sébastien Lorion <[email protected]> wrote:

> Creating lots of short lived objects in a short time provoke many Gen1
> which artificially promotes other objects to Gen2 or Gen3. You then
> get what Rico Mariani calls a mid-life crisis.

You have your gen indexes shifted up by one :)

Creating lots of *short-lived* objects is not usually a problem (ideally
you'll be doing actual work, not just allocating), as long as you don't
push gen1 objects into gen2. Gen1 should ideally only hold objects that
couldn't be collected while collecting gen0 simply because they're
currently in use, but will have died by the time a gen1 collection comes
around. Thus, unless you're (ab)using gen1 by virtue of keeping a bunch
of stuff around while doing all this allocation, the cheap creation
stays cheap.

In a bit more detail: if you have a call stack that, when simplified,
looks like this:

ProcessRequest()
{
    stuff = MakeBigObjectGraph();
    loop (lots_of_times)
    {
        MakeAndDiscardShortLivedObjects();
    }
    LengthyProcessing(); // more likely problem
    Process(stuff);
    // discard stuff
}

... then you may be in a bit of trouble, if the usage characteristics of
MyRootMethod don't give the GC a chance to tune gen1 size to be bigger
than the size of the thing returned by MakeBigObjectGraph +
(lots_of_times / gen0_collection_rate_in_loop_iters) *
average_objects_size_in_use_in_loop_body.

Given that most .NET code runs on servers, and most servers have a
predictable request/response pattern, the GC should be able to tune gen1
size appropriately. But measure, of course - both time in GC and with
profiler / windbg to check that wrong objects aren't being promoted and
that gen1 size is as expected.

The above breaks down if the ideal gen1 size would be "too big" (a
different problem - gen1 gets expensive, instead of gen2, and would
probably need redesiging the code) - i.e. MakeBigObjectGraph is too
large, or other processing code takes too much time. But hopefully it
can be seen here that the problem is keeping "stuff" alive too long (in
real time) or making it too big, not the number of short-lived objects.
If the objects truly are short-lived, collecting gen0 should deallocate
it almost completely every time (i.e. promote almost nothing to gen1),
thus making a gen1 collection quite rare, and therefore mid-life crisis
very rare. LengthyProcessing() is more likely a source of problems,
preventing the collection of "stuff".

> http://blogs.msdn.com/ricom/archive/2003/12/04/41281.aspx

-- Barry

-- 
http://barrkel.blogspot.com/

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com