Performance issue with childDataPortal.FetchChild on large readonly collections

[sacrejohn]

Hi,

I'm using the Last CSLA version to populate a readonly child collection with around 3500 elements. I've noticed a significant performance difference when using childDataPortal.FetchChild(reader) compared to directly instantiating and populating the child objects.

Here are two versions of my code:

Version 1 (standard approach – ~450 ms):

while (reader.Read())
{
    this.Add(childDataPortal.FetchChild(reader));
}

Version 2 (manual instantiation – ~250 ms):

while (reader.Read())
{
#pragma warning disable CSLA0011 // Find CSLA Business Objects That Are Created Outside of an ObjectFactory
    var c = new Child();
    c.Fetch(dalChild, reader);
    this.Add(c as C);
#pragma warning restore CSLA0011
}

As you can see, version 2 is about 200ms faster.

In this scenario, the Child object is readonly, with no business rules, and is only used for data display. I understand that childDataPortal.FetchChild provides lifecycle management, but in bulk operations this overhead adds up quickly.

Has anyone else encountered this performance issue?
If so, what is the recommended approach for high-performance loading of large readonly child collections?

Thanks!

[StefanOssendorf]

Hi,

you are correct that using the (Child)DataPortal methods introduce overhead to instantiation.
Without seeing the actual implementation of Child I can't say what's probably going to be not working. But at least your Child does not have a valid ApplicationContext instance supplied to your instance.

Which version of CSLA are you using? That's relevant to provide possible solutions for this problem.

[Bowman74]

Yes, this is absolutely going to add overhead. It sounds like for this instance, unless you have a remote data portal, you are using none of the features that CSLA provides you. CSLA is an abstraction that gives you many features around business rules, remote access of data, authorization rules, transaction levels, etc. If you are using none of that and your primary concern is performance, any and all layers of abstraction are going to hurt that performance, including CSLA.

For that matter your more performant approach is an abstraction layer as well and will not perform as well as just displaying the data reader's data directly.

If I were to take a guess, a lot of the difference in the performance you measured is coming from the ServiceProviderMethodCaller.cs class.

[rockfordlhotka]

You may be able to get away with Option 2 if you don't use new and instead use applicationContext.CreateInstance (I think).

The new keyword will not properly initialize the new child object with the application context, and so will cause issues at some point later in the execution.

[sacrejohn]

Thank you all for taking the time to read and respond to my post — I really appreciate your input.

I’ve continued my testing within the context of a web API, and wanted to share a quick follow-up. My original post was mainly driven by significant performance differences I observed during API startup. In those cases, using Csla resulted in noticeably higher latency.

I assume CSLA requires some degree of memory allocation or “warm-up” before reaching optimal performance. Once the API has sufficient memory available, the differences become minimal. For a collection of around 3,500 items, the standard CSLA approach adds about 30 ms, while the alternative using CreateInstance adds 17 ms.

That said, I assume using CreateInstance directly is probably not the recommended approach and could introduce side effects down the line. I originally chose CSLA for my API to ensure a unified and consistent codebase. However, I realize that if I’m not leveraging CSLA features for simple read-only operations, it might be better to bypass it altogether for those specific cases.

For now, I’ll continue as is and see how it goes in practice.

Thanks again to everyone who contributed and helped me out!