Hi

I am currently running some profiling on my LLBLGen entities, and have noticed the following behaviour... (Adapter, debug build of both LLBLGen and client code)

I am processing a collection of 1000 objects, and on each object am setting a single property to a new value

For Each CDR in CDRs
                CDR.Status = CDRStatus.Priced
Next

This is taking upwards of 5 seconds - the profiling reveals that the delay is all at the following line in

Public Overrides Overloads Function SetNewFieldValue(fieldIndex As Integer, value As Object) As Boolean

in the CDR Entity

MyBase.PostFieldValueSetAction(toReturn)

What is this line doing and why is it taking so long...?

Cheers

Matt

Further information

This behaviour only occurs when setting the property on entities which have been retrieved from the db. When setting it on new entites the 1000 calls to SetNewFieldValue run in less than .03 of a second (total)...!

Any thoughts welcomed

Is your collection bound to a grid or something?

No, this is all server side. I also do not have any event handlers bound to the itemchanged events...

MattTrinder wrote:

No, this is all server side. I also do not have any event handlers bound to the itemchanged events...

The field you set to a value, is that an FK field? The method you mentioned raises the EntityContentsChanged event. This events can be picked up by other entities, which for example have mapped fields on related fields. So if you load it from the db, do you use a prefetch path, or is the collection just a flat collection of entities, which don't contain any other entities?

Still, the slow down is remarkable indeed...

Yes, it is a FK field, and the related entity is NOT loaded in a prefetch path.

Would you please post real code snippets of your fetch routine, and the updating loop?

Also it might be helpful to know what RuntimeLibrary version you are using. (SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll -> RightClick -> Properties -> Version -> File version)

Thanks

CDRs are loaded using

m_DA.FetchEntityCollection(CDRs, CDRFilter, MaxRecords, CDRSort)

then

For Each CDR In CDRs
        CDRPrice = New CdrpricingEntity
         'set various properties of CDRPrice
        CDR.Cdrpricing.Add(CDRPrice)        
        CDR.Status = CDRStatus.Priced           
Next

so nothing out of the ordinary...

1.0.20051.60224

Will look into it.

[Test]
public void FkManipulationTest()
{
    EntityCollection orders = new EntityCollection(new OrderEntityFactory());
    using(DataAccessAdapter adapter = new DataAccessAdapter())
    {
        adapter.FetchEntityCollection(orders, null);
    }

    Console.WriteLine("Start of manipulation of {0} entities", orders.Count);

    DateTime start = DateTime.Now;
    foreach(OrderEntity order in orders)
    {
        order.EmployeeId++;
    }
    DateTime end = DateTime.Now;

    Console.WriteLine("End of manipulation");

    TimeSpan delta = end.Subtract(start);
    Console.WriteLine("{0}", (delta.TotalMilliseconds / 1000.0f));

    EntityCollection orders2 = new EntityCollection(new OrderEntityFactory());
    for (int i = 0; i < 818; i++)
    {
        orders2.Add(new OrderEntity());
    }

    start = DateTime.Now;
    foreach(OrderEntity order in orders)
    {
        order.EmployeeId++;
    }
    end = DateTime.Now;

    Console.WriteLine("End of manipulation");

    delta = end.Subtract(start);
    Console.WriteLine("{0}", (delta.TotalMilliseconds / 1000.0f));
}

prints 0.3 seconds. (818 entities). In a unittest through testdriven.net, so a little overhead here and there, debug build.

The empty entity manipulation also displays this. EmployeeId is an fk.

WHen I follow the SetNewFieldValue in the generated code, I then call into PostFieldValueSetAction, which raises EntityContentsChanged, which is then picked up by the collection, which then tries to raise a ListChanged event. Though as nothing is bound to that event, nothing happens. I then end up in OnEmployeeIdChanged though also nothing is bound to that event (EmployeeIdChanged), so I don't go anywhere but continue with the next iteration.

Often when a slowdown happens in an event producing routine, it's due to the fact that the event ends up in an expensive routine, like updating a grid or something.

I will have a play tommorrow and see if i can identify any further clues...

Frans

I have created a test which demonstrates the problem, and attached the files to my original help desk question...

Thanks

Matt

MattTrinder wrote:

Frans

I have created a test which demonstrates the problem, and attached the files to my original help desk question...

Thanks Matt

Thanks, will look into it.

Found a slowdown in the eventhandling which wasn't necessary. A fix has been made and will be posted to the website later today.

Simply amazing technical support.

Jeff wrote:

Simply amazing technical support.

Thanks Jeff .