[MonoDevelop] Fwd: Logging revisited

[Christian Hergert]

Looks good to me.

-- Christian

On 7/1/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> On 7/1/07, Lluis Sanchez <lluis at ximian.com> wrote:
> > El dg 01 de 07 del 2007 a les 02:03 -0700, en/na Christian Hergert va
> > escriure:
> > > Missed the list.
> > >
> > > ---------- Forwarded message ----------
> > > From: Christian Hergert <christian.hergert at gmail.com>
> > > Date: Jul 1, 2007 2:03 AM
> > > Subject: Re: [MonoDevelop] Logging revisited
> > > To: Jacob Ilsø Christensen <jacobilsoe at gmail.com>
> > >
> > >
> > > I had this feature, almost identical to your code, back in the initial
> > > implementation phase. We decided against it because it requires
> > > checking the StackFrame (like you do on patch line 18). I think the
> > > general consensus was that this is generally bad depending on
> > > velocities of logging or what-have-you.
> >
> > Yep, I don't like the idea of checking the stack frame at every log
> > call, I feel it may be slow. However, I don't have any real data. Maybe
> > you could do some tests?
>
> I did a quick test. Log an int in a for loop 1000 times getting the
> logger in two ways:
>
> 1) LogManager.GetLogger(typeof(MainClass))
> 2) LogManager.GetLogger(new StackFrame(1).GetMethod().ReflectedType)
>
> Scenario 1 took 7 ms on average whereas scenario 2 took 10 ms on
> average. This was done with no logging configured though. In a real
> scenario logging will probably be done to the console or to a file in
> which case the difference between the two probably becomes negligible.
>
> So, what now? :-)
>
> >
> > >
> > > That being said, I'm not necessarily against it either ;-)
> > >
> > > -- Christian
> > >
> > > On 7/1/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > > On 7/1/07, Christian Hergert <christian.hergert at gmail.com> wrote:
> > > > > I hate to say it, being that I did the original implementation of the
> > > > > logging, but I am a fan of doing the logging via log4net directly
> > > > > rather than through the proxy as we have now. I can understand it
> > > > > might be moot for something like this, but for server apps, its a
> > > > > godsend to have the reconfigurability of what gets logged, where, and
> > > > > how.
> > > >
> > > > Yes, I like direct logging via log4net better too. But at least my
> > > > patch lets you know where the log came from instead of always
> > > > ILoggingService, so now you can actually do per type configuration.
> > > > The where and the how is still possible with the current
> > > > implementation or am I misunderstanding something?
> > > >
> > > > >
> > > > > Food for thought,
> > > > >
> > > > > -- Christian
> > > > >
> > > > > On 6/30/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > > > > This patch is better.
> > > > > >
> > > > > > On 6/30/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > > > > > Hi.
> > > > > > >
> > > > > > > Some time ago there was some discussion about MonoDevelop's use of
> > > > > > > log4net. Right now all logging seems to come from ILoggingService due
> > > > > > > to:
> > > > > > >
> > > > > > > LogManager.GetLogger(typeof(ILoggingService));
> > > > > > >
> > > > > > > in DefaultLoggingService. This is not very informative. I have
> > > > > > > attached a patch which looks at the stacktrace to attempt to determine
> > > > > > > the calling type. It is rather hardcoded right now, but works for a
> > > > > > > debug build (a release build might invalidate it due to e.g. inline
> > > > > > > method optimizations) of MonoDevelop. To make it more accurate it
> > > > > > > could be changed to traverse the stacktrace until a type different
> > > > > > > from ILoggingService was found.
> > > > > > >
> > > > > > > Is this patch ok or should it be changed to traverse the stack for the
> > > > > > > calling type? Or do we want log4net dependencies in all classes that
> > > > > > > need logging?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Jacob
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Monodevelop-list mailing list
> > > > > > Monodevelop-list at lists.ximian.com
> > > > > > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > _______________________________________________
> > > Monodevelop-list mailing list
> > > Monodevelop-list at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> >
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> >
>