Performance of LoadProperty Method

rlhiggin — Fri, 27 Apr 2012 17:11:14 GMT

Hi folks,

My team is working on a WPF application using CSLA 4.2.1 for our business layer implementation. We have one area within our application that currently displays a list of 5633 info objects. This list is taking approximately 3.0 seconds to load. So, I decided to investigate in order to determine what the bottleneck is. I discovered that the culprit is in the LoadProperty(IPropertyInfo propertyInfo, object newValue) method on ReadOnlyBase<T> that is being called to populate the objects from a data reader.

This particular info object has 33 fields which means that LoadProperty is being called 5633 * 33 or 185,889 times in order to create the list we are trying to display. Upon further inspection, I discovered that this LoadProperty method is doing some pretty heavy lifting via reflection in order to set the field manager properties. I also noticed that a lot of this heavy lifting could be done during type initialization rather than each time a property is loaded.

I wanted to try this idea out to see if it would work and to see whether or not the performance would improve noticeably. What I came up with was this:


public class MyInfoObject : ReadOnlyBase<MyInfoObject>
    {
        private static readonly Dictionary<IPropertyInfo, System.Reflection.MethodInfo> genericPropertyMethods;

        static MyInfoObject()
        {
            genericPropertyMethods = new Dictionary<IPropertyInfo, MethodInfo>();

            var methods = typeof(MyInfoObject).GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);

            var loadPropertyMethod = methods.FirstOrDefault(x => x.Name == "LoadProperty" && x.IsGenericMethod);

            var cslaPropertyFields = typeof(MyInfoObject).GetFields(BindingFlags.Static | BindingFlags.NonPublic).Where(x => x.FieldType.GetGenericTypeDefinition().IsAssignableFrom(typeof(Csla.PropertyInfo<>).GetGenericTypeDefinition()));

            foreach (var item in cslaPropertyFields)
            {
                var current = (IPropertyInfo)(item.GetValue(null));

                genericPropertyMethods.Add(current, loadPropertyMethod.MakeGenericMethod(new[] { current.Type }));
            }
        }

        protected override void LoadProperty(IPropertyInfo propertyInfo, object newValue)
        {
            genericPropertyMethods[propertyInfo].Invoke(this, new[] { propertyInfo, newValue });
        }
    }

The goal here is that instead of creating a generic method to access the property storage every time LoadProperty is called, we create all of the generic methods that will be needed one time at type intialization via a static constructor. We then store those methods in a static dictionary so they can be accessed by all instances of the type. Finally, the LoadProperty method is overridden to look up and invoke methods that are stored in the static dictionary rather than using the base implementation which would run through all the reflection code again.

The results of this experiment were exactly what I expected -- faster performance. The time to load the list was reduced from approximately 3.0 seconds to approximately 1.0 seconds.

This particular scenario was just a test that I setup within our system to gauge performance for loading larger lists. We will have other objects that have roughly the same number of properties that get loaded from the database and may eventually have 10-20x as many records returned once the software is fielded. In the interest of keeping our architecture scalable, we are considering implementing this logic in a generic base class such as this:


public class CustomReadOnlyBase<T> : ReadOnlyBase<T>
    {
        private static readonly Dictionary<IPropertyInfo, System.Reflection.MethodInfo> genericPropertyMethods;

        static CustomReadOnlyBase()
        {
            genericPropertyMethods = new Dictionary<IPropertyInfo, MethodInfo>();

            var methods = typeof(T).GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);

            var loadPropertyMethod = methods.FirstOrDefault(x => x.Name == "LoadProperty" && x.IsGenericMethod);

            var cslaPropertyFields = typeof(T).GetFields(BindingFlags.Static | BindingFlags.NonPublic).Where(x => x.FieldType.GetGenericTypeDefinition().IsAssignableFrom(typeof(Csla.PropertyInfo<>).GetGenericTypeDefinition()));

            foreach (var item in cslaPropertyFields)
            {
                var current = (IPropertyInfo)(item.GetValue(null));

                genericPropertyMethods.Add(current, loadPropertyMethod.MakeGenericMethod(new[] { current.Type }));
            }
        }

        protected override void LoadProperty(IPropertyInfo propertyInfo, object newValue)
        {
            genericPropertyMethods[propertyInfo].Invoke(this, new[] { propertyInfo, newValue });
        }
    }

This would allow all of our business objects to have the same behavior. Because of the way .NET handles static members in generic types, I believe that at run time, each read only business object type, T, would get it's own generic type, CustomReadOnlyBase<T> , which means we would have one static dictionary of methods for each read only business object.

The fact that this implementation is not already in the CSLA ReadOnlyBase<T> makes me question whether or not this is actually a good idea. The performance benefit in my test scenario was obvious, but I'm curious if there are any other implications that I may have overlooked.

So, while this thread was mostly intended to be a discussion, I do still have 2 questions:

1.) Is there a better way to get the performance increase that we are looking for?

2.) Is there a reason the reflection code was being run in every single call to LoadProperty rather than one time for type initialization? Or, to reword this question, is there a reason I should not create a CustomReadOnlyBase<T> with this implementation?

Seeking Design advice (Silverlight / MVVM )

Jack — Fri, 17 Jun 2011 16:49:29 GMT

I'm looking for some general design advice as I revamp my framework and core application to 4.x. I have a lot of old and poorly designed code due to it being a first time CSLA project and Silverlight etc. etc.

My biggest struggle seems to be about how to handle subsets of data. My application is 90% readonly but involves lots of slicing and dicing on the same data from different perspectives and then performing single or bulk operations across select chunks. Some of those chunks represent children in a hierarchial relationship so that means refreshing parents and potentially checking the relationships between children.

The easiest example is that I have a DataEntryTask object in the system that at the bottom level belongs to a participant. One has to manage and ultimately enter test data for a single subject. The task has a schedule and various states (completed/cancelled/entered/ and then time related info).

However there are umpteen ways of dealing with the task depending on one's role. I need to manage:

All project tasks
All tasks at a site (1:x projects)
All tasks assigned to Resource X
All tasks for Participant Y
All tasks for Test Z

etc.

Each scenario uses the same basic object but influnces different parts of the workflow. This means a lot of re-use of the same data so I'm trying to avoid huge data retrievals.

What I'm finding is that I built giant UOW object and then pulled back ReadOnly lists and EditableLists. I'm then wrapping the individual items in ViewModels and presenting them to the UI that way. In essences I don't seem to care about the xxxList stereotypes as they just seem to get in the way. I still need the UOW objects as they load and manage all the lookup tables etc. but I'm struggling on how to better manage this. I do a lot of loading a subset of data and then appending and then removing / refreshing etc. That doesn't work at all with the existing list StereoTypes. I'm really just using them as a transfer mechanism through the data portal (maybe not such a bad thing).

I'm wondering if I would be better served with a set of CommandObjects that pulled lists from the DB and then my UOW just dealt with IEnumerable<MyClass>.

Maybe I don't need to be using xxxList objects and just having managed properties that are List<xxx> instead?

Thanks

jack

Search results matching tag 'Lists'

Performance of LoadProperty Method

Seeking Design advice (Silverlight / MVVM )