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
|
While looking into a performance issue with LightSpeed 4 I noticed a weird call in the profiler "Resources.get_ExpectedEntityStateNew()", after some additional profiling it turns out that the resource call is extremely slow. Some additional investigation showed the following code in reflector: public override void Add(Entity entity) Using Attach instead of Add was significantly faster (adding 500.000 records went from 12 minutes to less then 2 minutes). |
|
|
Hi Jerremy, Thanks for this. We always appreciate pointers on where we could eek out a little more performance. Doing some of my own tests I have found that the overhead of the resource call is there, but it's not as much as your tests are showing. What did cause the load was the assignment of the unit of work: entity.UnitOfWork = this; Test with the state == new check in place: Starting ADD test Note that the initial add is about 3 times more expensive than the second add later. This is because when we assign an entity to a UoW it checks to see if that UoW is different to the current one. If it is, then does some additional setup work. If not, it very quickly assigns it and moves on. Here's the same test with the resource check commented out - showing we could shave a little time down by improving the entity state check: Starting ADD test You can try this yourself by creating a new unit of work each time (so a new one at the start, a new one for the attach, and a new one for the second add). In this case you see these types of numbers: Starting ADD test This shows that Add and Attach are very similar but for that minor difference in the additional checks occuring. What does concern me however is your time is 12 minutes! As you can see from my tests, the time for half a million entities is barely over a second even on the expensive initial add operation! Something is indeed quite wrong if you're getting times like that. Admitedly my machine is very high end but it's not going to be hundreds of times more powerful. If you wouldn't mind, could you email me your tests so I can do additional testing here (be sure to not include any binaries): jd@mindscape.co.nz Kind regards, John-Daniel Trask |
|
|
I'll see if I can re-create the long processing times in a small test. Note that the 12 minutes included saving the records in batches of 500 with a SaveChanges(true). |
|
|
Ah! OK, generally tuning your batch size and when you hit save will have a huge impact on performance. Also, what identity method are you using? If using the KeyTable approach (the default) try upping your identity block size:
LightSpeedContext.IdentityBlockSize = 500; I've had experiences where I neglected to update the IdentityBlockSize and discovered most of the time was spent updating the keytable to fetch a range. LightSpeed saves extremely efficiently but if you're updating the keytable 50 times per batch save you'll run into performance problems. In my scenario a while back I dropped a HUGE save from 30 minutes to about 20s just by updating the IdentityBlockSize. I hope that helps, John-Daniel Trask |
|