| RE: [aus-dotnet] Whidbey Beta2 and the "Go Live" |
- From: Clarke Scott
- Subject: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live"
- Date: Thu, 02 Dec 2004 11:48:15 +1100
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I've entered a few at http://lab.msdn.microsoft.com/productfeedback/default.aspx -----Original Message----- From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On Behalf Of Mina Casiou Sent: Thursday, 2 December 2004 11:40 AM To: dotnet@xxxxxxxxxxx Subject: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live" Finula, I'd like to submit a feature request if allowed! Not sure of the exact place to ask for this, but hopefully you'll let us know. It's probably too late to ask for this, and it'll probably require a change to the CLR (read as - so it'll probably never happen!)... Anyway, here goes... Problem: Logging/Instrumentation etc... When attempting to write performance conscious logging code, for example, using the Logging App. Block and the EIF, the 1 liner's etc. If (eventPublishLogLevel > applicationLogLevel) And EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent)) Then : TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel, "Trace Message Event to be published.") : End If or If (eventPublishLogLevel > applicationLogLevel) And EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent)) Then : TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel, obj.SerialiseToXML()) : End If or ... 3 liner... If (eventPublishLogLevel > applicationLogLevel) And EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent)) Then TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel, obj.SerialiseToXML()) End If are common bits of code that we write in order to avoid the function call & parameter setup overhead etc. for a log message that will never happen because of the current loglevel. The 'if' statement makes the code look horrible. I try to fit it all on one line in order to not obscure the rest of the codebase with instrumentation code. Ideally, I'd be able to make the following call without the performance hit if the Raise event was configured to not log this message. I've found about a 30% performance gain/hit by the use of the 'if' statement. This is a big hit if not done. Unfortunately, the code now looks a little more ordinary that I'd like. I don't exactly have the best coding style myself! TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel, obj.SerialiseToXML()) Anyway, now to the feature request... It would have been nice to be able to do something like the following: TraceMessageEvent.Raise(myEventSource, eventPublishLogLevel, obj.SerialiseToXML()) public function Raise (myEventSource as EventSource, eventPublishLogLevel as Integer, [delayEvalParam] sMsgToLog as String) If (eventPublishLogLevel > applicationLogLevel) And EventSource.Application.IsEnabledForType(GetType (TraceMessageEvent)) Then EvalDelayEvalParams() 'now call the code to get this parameter... 'do the actual logging work... actualLog(myEventSource, eventPublishLogLevel, sMsgToLog) 'else do nothing... End If end function ...which you obviously can do...but the sMsgToLog variable has already been evaluated...i.e. obj.SerialiseToXML() has already been called to Serialize the Object to XML (a costly operation). but if you could do something like add an attribute to some of the input parameters...: [delayEvalParam] EvalDelayEvalParams()... then the ugly code could be removed from the calling code. Note that I could currently setup a function callback that the 'Raise' function could call, but this would still leave my calling code littered with crap (probably much worse than what it currently is...). Remember that a particular function can make numerous calls for instrumentation, and almost all of my functions do some sort of instrumentation. In the above scenario, the calling code would not be littered with 'if' statements etc. Which leads me onto another topic - method call interception... I had seen some code once, but forgot about it & lost it. I wanted to automatically log some stuff on method start and end. Anyone know where this sample code or framework is? Cheers Minas Casiou Information Systems Architect, Senior Consultant CSC Australia – Financial Services - Enterprise Business Solutions 26 Talavera Road Macquarie Park NSW 2113 Australia Ph: (02) 9034 3338 Mob: 0412 343 069 email: mcasiou@xxxxxxxxxx ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- "Finula Crowe" <finulac@microso To: <dotnet@xxxxxxxxxxx> ft.com> cc: Sent by: Subject: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live" dotnet-owner@sta nski.com 01/12/2004 04:36 PM Please respond to dotnet The BETA 2 of both the Visual Studio 2005 and Team System and the Express line is currently scheduled for Q1 of the calendar year (i.e. Feb/March time frame). The RTM date for VS 2005, Team System and Express is scheduled for 2nd half of 2005 so, Stephen has a pretty good "buddy" there ;-) Cheers Fin Finula Crowe Product Manager - Developer Tools Developer & Platform Evangelism Team 02 9870 2399 0414 899 301 To find out more about your local Microsoft Developer Tools community activities, go to: http://www.microsoft.com/australia/msdn -----Original Message----- From: dotnet-owner@xxxxxxxxxxx [mailto:dotnet-owner@xxxxxxxxxxx] On Behalf Of Stephen Sent: Tuesday, 30 November 2004 4:07 PM To: dotnet@xxxxxxxxxxx Subject: Re: [aus-dotnet] Whidbey Beta2 and the "Go Live" last I had confirmed, my microsoft buddy suggested a go live licence in March 2005 and final release in , well, 2005. Basicaly, it was suggested that if they have given the 2005 name then it will be released in 2005. S. On Tue, 30 Nov 2004 15:53:55 +1100, Clarke Scott <info@xxxxxxxxxxxxxxx> wrote: > > > > I've heard some rumors that Whidbey Beta 2 release has slipped again. > > Can someone confirm or deny this? > > If so, what is the likely release date, now? > > > > Thanks > > Clarke > > > > > > > > > > > > -- Mercantile Systems http://www.mspl.com _________________ You are a part of the Australian "dotnet" mailing list. To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com _________________ You are a part of the Australian "dotnet" mailing list. To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com bj橻h~^ -bjwhwx%Sˢ &ޱ {.n+lj � &ޱ ry-ڝX jg͢^n؇ray [hf ֧Hb u 0֧H _________________ You are a part of the Australian "dotnet" mailing list. To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx List managed by: http://www.stanski.com
(Click here for more information on the aus-dotnet mailling list)
- References:
- RE: [aus-dotnet] Whidbey Beta2 and the "Go Live", Mina Casiou
- Prev by Date: Re: [aus-dotnet] Dotnet exchnage rate service
- Next by Date: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live"
- Previous by thread: RE: [aus-dotnet] Whidbey Beta2 and the "Go Live"
- Next by thread: Re: [aus-dotnet] Whidbey Beta2 and the "Go Live"
- Index(es):