none
Computed fields are so slow

    Question

  • Hi,

    I read many articles and posts but my problem remains: computed fields are very very very slow. On a small 5 rows grid you can see each computed field cell being filled in one by one which is a poor user experience that can lead to total client rejection. I ended up moving my computed fields to columns in my database which I update with the updating events...

    I like LS a lot so I'm very disapointed and frustrated that I had to do this. Surely I'm doing something wrong! So here is another post (those I read are usually from 2011) to see if there something new with regards to that issue.

    Tks.

    Saturday, June 29, 2013 8:18 AM

Answers

  • I think it has to do with the complexity of the computed fields. Creating sub-queries inside those computed fields was never going to be fast. You also cannot sort on calculated fields in a grid either as you've probably already found. They are most useful for calculating things like Extended Price if you have Price and Qty when used inside a grid. In my own experience views or RIA services worked best for populating grids.


    Regards, Xander

    Monday, July 01, 2013 7:57 AM

All replies

  • I don't think you are doing anything wrong.  Performance of computed properties in the SL grid are terribly slow.  Although they improved performance of OData, the SL client is still slow overall.  Your solution of persisting the fields in the database is the best workaround, unless you want to create custom RIA services.  Computed properties work fine in a detail screen where you are working with one entity at a time.  It still drives me crazy to watch how fast my .net 3.5 EF web application with std gridview control displays all my data instantly.  Then I watch my LS SL client, loaded with all sorts of amazing features that I love, sputter to display a few rows...  If the SL client performance issues would be fixed, nothing could touch it.
    • Edited by Hessc Saturday, June 29, 2013 3:33 PM typo
    Saturday, June 29, 2013 3:33 PM
  • I actually disagree that computed properties are slow :). It is a bit like saying T-SQL is slow... It will be slow only if not used correctly! From my recollection, computed properties are executed on the tier where it is used. In this case, due to being displayed in the grid, it is used on the client tier and therefore a call back to the server needs to be made for each row when it is displayed. If you use the developer tools in Chrome to monitor the traffic between the browser and the backend you will probably notice all those additional calls. The answer may well be to do a database view and base the grid of that view or the RIA service as suggested above.

    Regards, Xander

    Sunday, June 30, 2013 8:47 PM
  • I'd be happy to use them correctly, but someone would have to explain me how to avoid these call backs to the server row by row then. Because if computed fields cannot be used in grids then what's the point? I thought about a view already but you cannot use a view in a master detail screen has it has no Relationship...

    Moreover, when I move from row to row in the master grid, the changes in the detail screen is immediate so the information is already loaded. Hence why all these call backs to the server for the computed field if the information is already available locally?

    Monday, July 01, 2013 7:49 AM
  • I think it has to do with the complexity of the computed fields. Creating sub-queries inside those computed fields was never going to be fast. You also cannot sort on calculated fields in a grid either as you've probably already found. They are most useful for calculating things like Extended Price if you have Price and Qty when used inside a grid. In my own experience views or RIA services worked best for populating grids.


    Regards, Xander

    Monday, July 01, 2013 7:57 AM
  • I don't know about RIA (I'l certainly look into it) but views cannot work for master/detail screens.
    With regards to sub-queries, I can see that you're right hence my post lol. Yet, I think it is so natural to display Total Amount in the grid of a master/details orders  screen that everyone expects it to be easy and fast!

    Any point of view on my latest comment repeated below?

    "Moreover, when I move from row to row in the master grid, the changes in the detail screen is immediate so the information is already loaded. Hence why all these call backs to the server for the computed field if the information is already available locally?"

    Monday, July 01, 2013 8:02 AM
  • Sorry, no... although my quick guess is that LS or EF is not clever enough to know that the client already has the data (how would it?)  and therefore makes the additional calls. What I always do is to run SQL Profiler in the background and also look at the Network/XHR trace in the Chrome developer tools window at the bottom. From that you can usually figure out what is going on and where you have to change what to optimise.

     

    Regards, Xander

    Monday, July 01, 2013 8:07 AM
  • Tks Xander,

    As far as I'm concerned I already made changes => I don't use computed fields anymore and added them as columns in my database. But I really think it's a pity that I had to do that.

    Monday, July 01, 2013 8:13 AM