Re: StringBuilder Extension: IsQuotedBy

Right, the "short lived" was misleading. I meant objects who are
normally not intended to stay around, but because of the way it was
coded/architected, they do stay around. That said, it's not because
allocation and gen0 collection are fast that it can be used as an
excuse for lazy coding. Allocating objects in a tight loop or methods
like GetHashCode() is still a big nono ...

Nice catch on gen1-2-3 :p I guess spending less time coding make you
go back counting like 99% of the world population ...

P.S. Barry vs Brady: so easy to mistake one for the other :)

Sébastien

On 2/14/08, Barry Kelly <[email protected]> wrote:
> 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(R)  http://www.develop.com
>
>
>  View archives and manage your subscription(s) at http://discuss.develop.com
>


-- 
Sébastien
www.sebastienlorion.com

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

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