Stop capturing in logging

[roji]

On a local 30k iteration Fortunes run, allocations were reduced from 2.5M instances (153.21MB) to 2.23M instances (146.99MB) (10% reduction in instances, 4% in bytes).

Interestingly, no discernible effect on RPS throughput at the perf lab. The GC must be doing its job quite well.

[AndriySvyryd]

@roji Those instances were probably never GC'ed

[roji]

I guess it's possible... Though I can see lots of GC runs occurring in DotMemory, and it would be a bit odd if these 10% of instances (4% of bytes) weren't touched...

In any case, always good to cut down...

[ajcvickers]

@roji The resulting EventDefinitionBase objects are rooted in a singleton service, which will be rooted in the internal service provider. In a typical application they will not be GC'ed. That being said, I don't know if this relates directly to capturing.

[roji]

I don't think this is related to the EventDefinitionBase - it's just about the lambda passed as an argument to EnsureInitialized; it used to reference the logger local variable, making it a closure and therefore a heap allocation. I just changed that to be a static lambda that gets the logger as a parameter.