CallSiteInformation - Prepare for fast classname lookup from filename and linenumber

[snakefoot]

Have an idea for how to optimize the callsite-layout-renderer, so it doesn't have to capture stacktrace for every logevent (only for the first logevent for a log-location).

One could use the caller-member-attributes to capture Member-Function, SourceFile-Name, SourceFile-LineNumber. And cache the ClassName-Lookup performed with StackTrace using the details from caller-member-attributes as cache-lookup-key (Maybe using MruCache).

To implement this correctly, then we need something like StackTraceUsage, but where it is WithCallSiteOnly, which is less than WithoutSource. Sadly enough any change to the StackTraceUsage will be a breaking change.

So instead one probably have to invent a new interface called IStackTraceUsageV2, and if a class implements both IStackTraceUsageV2 and IStackTraceUsage, then it will use IStackTraceUsageV2.

But all this interface-stuff will be a different PR. I just want to prepare for being able to provide the ClassName as CallSite-Information (Right now not a breaking change, as everything is still new in NLog 4.5).

[snakefoot]

@304NotModified If possible, please include this for NLog 4.5 RC2 :)

[codecov]

Codecov Report

Merging #2447 into master will decrease coverage by <1%.
The diff coverage is 56%.

@@           Coverage Diff           @@
##           master   #2447    +/-   ##
=======================================
- Coverage      81%     81%   -<1%     
=======================================
  Files         322     322            
  Lines       23145   23158    +13     
  Branches     2874    2878     +4     
=======================================
+ Hits        18851   18859     +8     
- Misses       3547    3551     +4     
- Partials      747     748     +1

[304NotModified]

Have an idea for how to optimize the callsite-layout-renderer, so it doesn't have to capture stacktrace for every logevent (only for the first logevent for a log-location).

One could use the caller-member-attributes to capture Member-Function, SourceFile-Name, SourceFile-LineNumber. And cache the ClassName-Lookup performed with StackTrace using the details from caller-member-attributes as cache-lookup-key (Maybe using MruCache).

I think this could work :) MruCache sounds like a good idea. Would be very nice to improve performance on this one!

To implement this correctly, then we need something like StackTraceUsage, but where it is WithCallSiteOnly, which is less than WithoutSource. Sadly enough any change to the StackTraceUsage will be a breaking change.

How is this a breaking changes? We could add a member to the enum StackTraceUsage? AFAIK it's not mandatory to keep the enum (backend) values "ordered"?

(Right now not a breaking change, as everything is still new in NLog 4.5).

So this is a must for NLog 4.5? I'm holding RC2 for this now.

[snakefoot]

Think enum values are compiled in as integer values. Only allowed to add at the end. Max is locked to 2 and the new value need to be added just after none.

…

Sent from my Samsung device

-------- Original message -------- From: Julian Verdurmen <notifications@github.com> Date: 03/12/2017 22:24 (GMT+01:00) To: NLog/NLog <NLog@noreply.github.com> Cc: Rolf Kristensen <sweaty1@hotmail.com>, Author <author@noreply.github.com> Subject: Re: [NLog/NLog] CallSiteInformation - Prepare for fast classname lookup from filename and linenumber (#2447) Have an idea for how to optimize the callsite-layout-renderer, so it doesn't have to capture stacktrace for every logevent (only for the first logevent for a log-location). One could use the caller-member-attributes to capture Member-Function, SourceFile-Name, SourceFile-LineNumber. And cache the ClassName-Lookup performed with StackTrace using the details from caller-member-attributes as cache-lookup-key (Maybe using MruCache). I think this could work :) MruCache sounds like a good idea. Would be very nice to improve performance on this one! To implement this correctly, then we need something like StackTraceUsage, but where it is WithCallSiteOnly, which is less than WithoutSource. Sadly enough any change to the StackTraceUsage will be a breaking change. How is this a breaking changes? We could add a member to the enum StackTraceUsage? AFAIK it's not mandatory to keep the enum (backend) values "ordered"? (Right now not a breaking change, as everything is still new in NLog 4.5). So this is a must for NLog 4.5? I'm holding RC2 for this now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2447 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AK-fnBB512znvZ5u1o9vmvCdnA9oPFxbks5s8xFygaJpZM4QzpoP>.

[304NotModified]

Think enum values are compiled in as integer values. Only allowed to add at the end. Max is locked to 2 and the new value need to be added just after none.

It's not required to have Max as the highest value? Yes, its nice, but no breaking changes are better. Are we using lower/higher comparison on the enum?

[304NotModified]

Are we using lower/higher comparison on the enum?

Ow I see StackTraceUsageUtils.Max - although it's internal

[snakefoot]

Anyways those enum details are for another PR :). Just wanted to markup the playing field

…

Sent from my Samsung device

-------- Original message -------- From: Julian Verdurmen <notifications@github.com> Date: 03/12/2017 23:12 (GMT+01:00) To: NLog/NLog <NLog@noreply.github.com> Cc: Rolf Kristensen <sweaty1@hotmail.com>, Author <author@noreply.github.com> Subject: Re: [NLog/NLog] CallSiteInformation - Prepare for fast classname lookup from filename and linenumber (#2447) Are we using lower/higher comparison on the enum? Ow I see StackTraceUsageUtils.Max - although it's internal — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2447 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AK-fnHlj2SoncY8xPMg674yRyuf2vnNKks5s8xzegaJpZM4QzpoP>.

[304NotModified]

true :)