Object Auditing

Question

currently we have quite a chunky auditing system for objects within our application, the flow goes like this..

-Class implements an interface

-Interfaces forces the class to override some methods for adding properties that need auditing to a List of KeyValuePairs

-Class is then also needs to recreate the objects state from a list of key value pairs

Now the developer needs to add all this to there class, also our objects change quite often so we didn't just serialise the class.

What I would like to do is to use attributes to mark the properties as auditable and then do everything automatically so the developer doesn't really need to do anything.

My Main question is - I know people always say reflection is slow, how slow are we talking? what performance hits am I going to get from looking through the class and looking at attributes against a property and then doing any required logic?

thanks for any help

Ste,

score 1 · Accepted Answer · answered Jan 05 '12 at 10:13

It's hard to give a specific answer because it depends on what adequate performance is for your application.

Reflection is slower then normal compiled code but when worrying about performance problems it's always better to have something that works and then use profiling to find the real performance bottleneck and optimize.

Premature optimization could lead to code that's much harder to maintain so your developers will be less productive.

I would start with using reflection and write a good set of unit tests so you know your code is working. If performance turns out to be a problem you can use the Visual Studio profiler to profile your unit tests and discover the bottlenecks.

There are some libraries that can speed up reflection or you could use Expression trees to replace your reflection code if it's to slow.

score 0 · Answer 2 · answered Jan 05 '12 at 10:05

0

If the performance ok or not depends on your app context. So it's difficult to say if it is slow or fast for you, you should try it by yourself.

Most probably, imo, it would give pretty acceptable performance, but again I have no idea where you gonna use it.

Like other solutions that come to my mind, could be:

Sqlite, where to save the key/value data
Aspect Oriented Programming (like a PostSharp) to generate a data in compile time.

But the first thing I would try, is a Reflection, just like you think.

answered Jan 05 '12 at 10:05

Tigran

61,654
8
86
123

Thanks for the response, I didn't plan on using PostSharp originally to avoid reflection and generate all the code needed BUT my company will not pay for any enterprise use sadly. Ill try Reflection and try and get some bench marks! – Steoates Jan 05 '12 at 10:08

score 0 · Answer 3 · edited May 23 '17 at 12:03

0

Reading this response from Marc I would suggest that Reflection should be fine for most application needs.

Before making any fundamental changes I would suggest running a profiler to find the bottlenecks in your code. If you identify the reflection / auditing process is the major pain point use an IL Emit and try again.

edited May 23 '17 at 12:03

Community

1
1

answered Jan 05 '12 at 10:06

Kane

16,471
11
61
86

score 0 · Answer 4 · answered Jan 05 '12 at 10:14

Reflection is the way to go here. If it's too slow(measure!) you can throw in a bit of caching, or in the worst case generate an Expression<T> and compile it.

There are two phases in your problem:

Figure out which properties you want, and return a list of their PropertyInfos. You need to do this only once per type, and then you can cache it. Thus performance of this step doesn't matter.
Getting the value of each property with PropertyInfo.GetValue.

If this step 2 is too slow, you need to generate an Expression in step 1, and the overhead over manually written code goes down to a single delegate invocation.

Object Auditing

4 Answers4