This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Note: This is done without doing any lookups in the database. Everything is in memory, dictionaries. |
|
|
I can confirm the performance issue depicted by Thomas. I've done extensive testing, and here are my test results: Test with small dataset (adding and saving 30 000 address objects with references to person) Test 0:
Tests with larger dataset (100 000 objects) Test 1:
My test project can be located at: http://dl.dropbox.com/u/12428344/lightspeed_performance/TestLightspeed.zip The conclusion is the following: When using object references and a large dataset (100k vs 30k) the performance in lightspeed scales sublinearly. While it takes 11 seconds to add 30k objects, it takes 200 seconds to add 100k, 18 times slower performance instead of 3 times slower performance. As you can see, Entity Framework doesn't suffer from this defect, wall time wise it scales almost linearly with the amount of objects added to the context. Also setting Id references is significantly faster than setting object references. For us, this is a major issue because we use Lightspeed to do a rather large import job (saving about 2 million entries, and we haven't been aware of the performance issue when setting object references instead of Id references, therefore our import application uses object references and is extremely slow running and leaves a rather large memory footprint. Can we expect this issue to be fixed, or do we have to change our application to use Id references?
Best regards, Safurudin Mahic
|
|
|
Cheers for the sample on this; We are having a look into this and having a review with a view to implementing optimizations to improve the perf here. I will post back once we have had a better look into this and assessed what we may be able to do here.
Thanks! Jeremy |
|
|
An update on this - we have tracked the issue here down to the ListChangedEvent which gets fired from an object being added in to its parents collection (reverse association from the child). This is definitely intended behavior, however in these bulk load scenarios As a workaround you can turn off this event being raised (even just temporarily while you perform the bulk load) which will remove the performance impact. Turning this off will get you back roughly to the same performance as Id assignment. To turn it off: Assuming a model of Person which has many Addresses, where you are performing the following assignment, Address.Person = person, then set person.Addresses.RaiseListChangedEvents = false;
Jeremy
|
|
|
Great stuff Jeremy, thanks. I believe it would also be of use if Lightspeed could provide a unified way on turning on/off the ListChangeEvents globally for all Entities in the UnitOfWork in such bulk load scenarios. Because we have many many associations in our models, keeping track of whether each individual one has the events on or off with each association would be a tedious job. Something like UnitOfWork.RaiseListChangedEvents = false; Do you consider this to be a feasible feature?
Safurudin |
|
|
Yes - we are definitely looking at implementing a "global" switch of this nature :) Thanks for confirming that it is the desired approach! We will let you know once we have some progress here to report on.
Thanks! Jeremy |
|