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
|
Hi, we have deployed a software (which uses LightSpeed) to a client in the end of 2012. Basically everything went fine but with a growing db quite some performance issues popped up. We were able to track them down and fix them but recently we had to learn the big difference between the following to snipplets: First (0.4 seconds):
Second (1.7 seconds):
As you can see we have a one to many association between SomeOnes and Many and the only difference between the code. For my measurements I created two SomeOnes and 100k Manies. If I turn on SQL-Logging in LightSpeed for the second example I get the following:
I was surprised to see five instead of three queries but I can guess why this happens. After turning on my profiler it was obvious that 99.999% of the cpu-time was consumed by the Many-Constructor. This situation means for us that we may have a set of tiny mines build into our software that might/will explode from time to time and blow up the complete systems performance as the db is still and will continue growing. |
|
|
What version are you currently using? The reason I ask is that we added in an optimisation to 4.0 last year to defer lazily loading collection when object wire-up occurs until you actually touch the collection directly which avoids the problems you are describing, namely a lazy load of collections due to association wire-up which in the case of a large number of Many's could lead to a lot of time spend hydrating these. If you are able to produce this behaviour against a current nightly build would you be able to send through a small repro of this please and I can have a look into whats occurring.
|
|
|
Hi, we downloaded the latest version that is available for us (22.12.2012) and this issue seems to be solved. I tried to update our software to this version only to see that it wouldn't even start anymore. This was one of the reasons we stopped updating as we do not have the time or the money to spend at least a week of LightSpeed-bugtesting after a simple update. Regards, Dennis |
|
|
A approach you can take to work around the behaviour without updating is to detach the in-memory SomeOne instances while performing the assignment and then reattach them afterwards. e.g.
This does obviously rely on you being able to identify which objects are going to be involved, although at the expense of potential database hits you could approach this by fetching by Id for some2Id and many.OneOfSomeId via a UnitOfWork.FindById<> query rather than dealing with known objects as such. If those objects are already loaded into the UOW then you wont have the database calls and you will certainly be needing to remove them from UOW to avoid the wire-up, if there were not already in the UOW though you would take a hit of some redundant database calls in loading in those objects before they were specifically needed.
|
|
|
Hi, thanks for your reply. We are already using Ids where possible and short living UnitOfWorks. That's also why this only happens in some rare situations which - none the less - have the possibility to get the whole system performance down. Therefore it currently seems like we will extend our subscription, upgrade to LS5 and start testing again. Regards, Dennis |
|