Abysmal Clone() performance

[michaelcsikos]

In this particular app, users can have multiple views of the same data open at the same time with different filters, etc. When a record is saved, all the screens need to be reloaded. Instead of each screen hitting the database to reload, I want to load the list once and then provide a Clone() to each screen to bind its own grid.

It seemed like a good idea until I ran some tests. Loading the list from the cloud database takes 1.7 s. Cloning the list is taking over 4.0 s. Why is it so?

[StefanOssendorf]

Are you cloning only once or multiple times?
The cloning itself uses serialization under the hood to get a clone.

[michaelcsikos]

I'm creating a clone for each of the screens that are loaded.

[StefanOssendorf]

How many times do you clone to get the 4s you stated?
Cloning the object should be pretty constant. That means cloning it once takes maybe 1s. So cloning it 4 times sequentially will take 4s.

[michaelcsikos]

Every clone is taking about 4 s.

[StefanOssendorf]

Ah okay. Sorry I got that wrong.

Next question: Which UI stack are we talking about?

[rockfordlhotka]

Is this on a low-end device like a phone or something?

The data access (via the data portal) does at least one "clone" as it serializes and deserializes the data to flow over the network - or between the logical server and client if using LocalProxy.

Is it possible that the object is bound to the UI while it is being cloned? Maybe there's some weird data binding thing going on?

[rockfordlhotka]

I wonder what is in your object graph that causes such a slow clone? A massive object graph? A lot of DTOs inside the graph? a lot of big binary images?

Can you run a profiler or otherwise explore what's in the graph that is causing the slowdown?'

Maybe a property that references a non-CSLA object?

Are you using the BinaryFormatter or MobileFormatter?

[michaelcsikos]

Each Info object has its own CSLA read-only list with an average of 10 items. This seems to be the main cause of the slow performance. The main list has ~1500 items, and there are ~15,000 sub-items in total. We're using the default formatter for 4.11.2, whatever that was.

[rockfordlhotka]

That is a big graph for sure. Still, it isn't that uncommon to have a large object graph.

What is your "Load list" timing? The data portal fetch call?

[rockfordlhotka]

fwiw, I am able to replicate what you are seeing in current CSLA, where I have a fetch that takes 2.8 seconds and a clone that takes 7.5 seconds on the same graph.

(fortunately I already had a test app with a very large object graph)

I don't have time to try and figure out the reasoning behind this right now, as I'm working toward the CSLA 9 release in a couple weeks. I suspect this is one of those things that'll take some meticulous debugging work - and might be something that just is what it is.

My suggestion to you is to try and think about ways to refactor the user workflow such that perhaps you could load parts of the graph, or avoid the cloning.

[michaelcsikos]

From a (LocalDB) database with ~1200 info objects:

Load list             00:00:00.2267309
Load from cached DTOs 00:00:00.1466644
Clone list            00:00:02.9197298

and the cloud database with ~1500 info objects:

Load list             00:00:00.7914028
Load from cached DTOs 00:00:00.2210326
Clone list            00:00:03.9942550

The temporary cache is working quite well. There's still an unavoidable delay rebinding the data to each grid as that has to be done on the UI thread, but overall it feels much snappier.

For simple structures the Clone() performance seems perfectly fine. I guess it's just something to be aware of, and a workaround like a DTO cache could be the answer for complex graphs.