locked
You really need to focus entirely on improving dev time performance. RRS feed

  • Question

  • I have a project has more than 200 tables, terrible dev time performance, since I already got i7 3770k overclocked, sansung 128g  840 pro ssd, 16G memory, but still way far away to fluence experience at all.

    Upgrading to v3 only makes performance worse, about -10% for whole as my personal observation.

    Sluggish, Sluggish, Sluggish, how can I hold on.

    No one has a project has more than 200 tables? 

    Friday, April 12, 2013 2:57 AM

All replies

  • I thought I just had a slow pc...  +1
    Friday, April 12, 2013 3:06 AM
  • I could put up with the poor development performance, somewhat, if the finished application client wasn't so damned slow.  The Silverlight client is inexplicably slow.

    Free Visual Studio LightSwitch extensions: Elyl's Extensions

    Friday, April 12, 2013 9:44 AM
  • Amen to all that; performance is particularly tragic when modifying queries/paremeters in the designer, almost total slowdown.

    These and other performance issues have been pointed out ad-nauseum with no response, or at least, nothing official.

    I would like to make the point that, when update 2 was released recently, there was, published along with it, an extremely long list of fixes/improvements to VS2012. I scanned eagerly down to the LS section to find ONE entry, which needless to say had nothing to do with any of the numerous and oft-reported bugs/iritations going all the way back to LS Beta1.

    Go figure; I can't. And I've practically given up on getting definitive answers from anyone on the LS Team, despite numerous posts. Oh there's sometimes a 'workaround', but frankly it's just not good enough. Obviously they've been completely consumed by the HTML Client; lovely tech but as of yet incapable of use for full LOB applications. Since LS Silverlight was built for just that scenario, WHY don't they fix what is broken? It's not as if they are not aware, and have been for a very long time.


    Ian Mac

    Friday, April 12, 2013 2:11 PM
  • +1 from me...

    Friday, April 12, 2013 2:19 PM
  • I found how to resolve the design time performance, please take it seriously, you can really make cesign time performance much better, if you really hearing us.

    The reason why the design time performance so terrible is, whenever I changed anything of the Models(data model, screen model etc...), the validation and code generation methods will be called on Application's Idle event, which is in the main thread, of cours, this will cause the design time performance terrible.

    To solve the problem, you just have to call these methods on non-main thredad.

    Please listen to us, make this tiny change, we will get much better performance.


    Monday, May 13, 2013 6:44 AM
  • I created a visual studio extension to bypass the problem, here are the codes:

                var designTimeIdleWorkItemService = VsExportProviderService.GetServiceFromCache<IDesignTimeIdleWorkItemService>(Scopes.Local);
                designTimeIdleWorkItemService.GetType().GetMethod("InitializeIdleProcessQueue", BindingFlags.NonPublic | BindingFlags.Instance).Invoke(designTimeIdleWorkItemService, null);
    
                var activeQueuesQueryResult = designTimeIdleWorkItemService.GetType().GetField("activeQueuesQueryResult", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(designTimeIdleWorkItemService) as INotifyPropertyChanged;
                var onActiveQueuesChangedInfo = designTimeIdleWorkItemService.GetType().GetMethod("OnActiveQueuesChanged", BindingFlags.NonPublic | BindingFlags.Instance);
                activeQueuesQueryResult.PropertyChanged -= (PropertyChangedEventHandler)onActiveQueuesChangedInfo.CreateDelegate(typeof(PropertyChangedEventHandler), designTimeIdleWorkItemService);
                activeQueuesQueryResult.PropertyChanged += activeQueuesQueryResult_PropertyChanged;

      void activeQueuesQueryResult_PropertyChanged(object sender, PropertyChangedEventArgs e)
            {
                if (e.PropertyName == "Count")
                {
                    ThreadPool.QueueUserWorkItem(new WaitCallback(delegate
                    {
                        var codeGeneratorService = VsExportProviderService.GetServiceFromCache<ICodeGeneratorService>(Scopes.Local);
                        var designTimeIdleWorkItemService = VsExportProviderService.GetServiceFromCache<IDesignTimeIdleWorkItemService>(Scopes.Local);
                        var sortedQueues = designTimeIdleWorkItemService.GetType().GetField("sortedQueues", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(designTimeIdleWorkItemService) as IEnumerable;
                        var isInsideTransaction = (bool)designTimeIdleWorkItemService.GetType().GetProperty("IsInsideTransaction", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(designTimeIdleWorkItemService);
                        foreach (IDesignTimeIdleWorkItemQueue current in sortedQueues)
                        {
                            if ((!isInsideTransaction || current.IsValidInTransaction) && current.ContainsWorkItem)
                            {
                                if (current.Name == "IdleTimeCodeGenerator")
                                {
                                    codeGeneratorService.GetType().GetMethod("RunGenerators", BindingFlags.NonPublic | BindingFlags.Instance).Invoke(codeGeneratorService, new object[] { true });
                                    var forceSetToRun = (bool)codeGeneratorService.GetType().GetField("forceSetToRun", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(codeGeneratorService);
                                    if (forceSetToRun)
                                    {
                                        current.GetType().GetMethod("SetToRun").Invoke(current, new object[] { });
                                    }
                                    else
                                    {
                                        current.GetType().GetProperty("ContainsWorkItem", BindingFlags.NonPublic | BindingFlags.Instance).SetValue(current, false);
                                    }
                                }
                                else
                                    current.Process();
                            }
                        }
                    }));
                }
            }

    After doing this, the performance is way much better
    Monday, May 13, 2013 6:58 AM
  • Hey Ely,

    Sorry for just coming across this now.

    But what version of VS LightSwitch are you running?

    If it is Update 2 then I would expect a LightSwitch Silverlight application to be quite a bit faster when compared with a previous release.

    This is primarily due to us using a later version of WCF/ODATA in the Update 2 release that takes advantage of the much more light-weight JSON format.

    Just as an FYI - I have seen issues in the recent past where 3rd-party extensions were actually responsible for causing the performance issues.

    Thanks - Matt Sampson


    R. Matt Sampson

    Monday, May 13, 2013 5:43 PM
  • Hello Matt,

    which 3rd-party extensions can causing performance issues?

    robert

    (we have also sluggish app also at runtime) 

    Monday, May 13, 2013 5:59 PM
  • Hey Robert - 

    In the particular case I was referring to the vendor was notified about the performance issues with the extension (a couple months ago now).  So hopefully that would have already been addressed.

    What helped us figure this performance out was to simply remove extensions from the project (assuming this is possible) and then re-publish the project without and see if your performance improved.

    Let me know if that works for you.

    Thx - Matt S


    R. Matt Sampson

    Monday, May 13, 2013 6:22 PM
  • Can someone from the LS team please comment on Ryan's observation and workaround?  My design time performance is bloody terrible as has been posted by several others building medium to large applications.  My application does not use 3rd party extensions so that is not the issue. 

    The silverlight client performance problem is a separate matter that is also well documented throughout the forum.  Update 2 may have made it slightly (ever so slightly) better, but it is not even close to where it needs to be.  Have you tried to send 100K + rows to powerpivot over the odata service?  If so, please share your results.

    Thursday, May 23, 2013 1:53 PM
  • Hi Hessc,

    My workaround is not perfect, this will cause some problems in rare condition, but I will accept it, since this makes the design time performance much better, I hope the LS team will make a more stable solution.

    Thursday, May 23, 2013 2:00 PM
  • I hope so too, Ryan.  I love Lightswitch and all that is does, but some of the issues identified really need to be fixed for it to be viable.

    Thursday, May 23, 2013 2:07 PM
  • Hey Hessc-Tell me about this project size of yours a bit more. Can you give me a rough estimate to the number of tables/screens you have?  Are they "intrinsic" tables you modeled yourself in LightSwitch? I'd like to get a better idea of what your project looks like and what experiences are slow at design time.

    As for using PowerPivot in Excel to query data from what I assume is an OData Service produced by LightSwitch - PowerPivot is probably querying the OData Service using the "ATOM" format, which is very verbose.  You should follow up with the Office Excel/PowerPivot forums to see if there is a way to customize PowerPivot to use a less verbose format (like JSON) when querying OData Service. That's not something that LightSwitch has control over. We have to feed PowerPivot the data in whatever format it asks for. 

    In perspective - the LightSwitch Clients (in Update 2) use the less verbose JSON format and as a result both the Server and the Client are considerably faster.


    R. Matt Sampson

    Thursday, May 23, 2013 2:17 PM
  • Hi Matt,

    Appreciate your time on this.  The project specs are below.  I will certainly follow up RE powerpivot.  Thanks!

    - No. of tables = 48

    - No. of screens = 18 (working on adding many more now, I did the middle tier first)

    - No. of modeled queries = 150

    - Database is external SQL server database, no use of intrinsic database other than security.

    -Slow design experiences include:  Any designer, screen, entity, or query.  The only thing that is not slow is writing code.  Some designers are worse than others.  By far the worst is the screen designer when the screen members collection has 15 or more modeled queries added as sources for ACBs on the screen.  This can take a very long time (>20 minutes) to load once you try to change something on the screen (add a collection, change a description, add a method, etc., anything).  The next worst is the query designer.  It lags very bad when creating modeled query filters and parameters.  No wait like with the screen designer but it still lags pretty bad.  lastly, the entity designer lags when changing business types, adding computed properties or anything like that.  Hope this helps.

    Thursday, May 23, 2013 2:47 PM
  • Hi Matt,

    Appreciate your time on this.  The project specs are below.  I will certainly follow up RE powerpivot.  Thanks!

    - No. of tables = 48

    - No. of screens = 18 (working on adding many more now, I did the middle tier first)

    - No. of modeled queries = 150

    - Database is external SQL server database, no use of intrinsic database other than security.

    -Slow design experiences include:  Any designer, screen, entity, or query.  The only thing that is not slow is writing code.  Some designers are worse than others.  By far the worst is the screen designer when the screen members collection has 15 or more modeled queries added as sources for ACBs on the screen.  This can take a very long time (>20 minutes) to load once you try to change something on the screen (add a collection, change a description, add a method, etc., anything).  The next worst is the query designer.  It lags very bad when creating modeled query filters and parameters.  No wait like with the screen designer but it still lags pretty bad.  lastly, the entity designer lags when changing business types, adding computed properties or anything like that.  Hope this helps.

    Btw, same proble with use of intrinsic database.

    Thursday, May 23, 2013 5:57 PM
  • Hey Hessc,

    Here's what I did - on Update 2 I made a LightSwitch SL Client with 70 tables, 75 queries, and a couple screens. I added a ton of parameters and filters to a couple queries. And I added a ton of stuff to the screens as you mentioned.  Things definitely get a little bit slower (nothing that I would say we aren't already aware of as a team), but I never get anything close to the 20 minutes you mention. Honestly never get anywhere near a minute for screen rendering time when making changes to it.  I would say queries seem to slow down a little bit, and I will look into that one some more.

    Not sure what else to tell you, but if you are OK with it you are welcome to share your project out with me and I can investigate that some more on my own machine (BTW - using 4GB of RAM - 4 processors).  If you do want to share it out, just let me know and I can send you my email.

    -Thanks - Matt Sampson


    R. Matt Sampson

    Thursday, May 23, 2013 6:53 PM
  • Matt,

    Here's what I did,

    250+ tables, 100+ screens, 0 queries. This is fairly small size for a ERP application.

    Actually I have hold a lot of features not to be added in this application, a typical ERP normally will have 1000+ tables.

    I have also some applications within 100 tables, in this condition I don't have any performance problem, the more table added , the performance is slow down exponentially, you won't believe the how the terrible performance is if you have 200+ tables.


    Friday, May 24, 2013 12:35 AM
  • Matt,

    It seems like the screens that are bad are those that are the most query intense.  Some of my tables have 50 or so columns so queries against those tables have lots of params in order to power text box search filters and look ups for all the fks.  Lots of other queries are added to be used as sources for the look up ACBs.  Every field of every table in my project has a sentence long description (Ryan mentioned something about that being an issue).  Note this issue does not occur (for me) on the screens involving small tables where just a few queries are added to the screen members collections.  It is only those screens with ~15 queries that are lagging out.  Most of my table properties also have custom validation methods, property changed methods, controls that dynamically enabled, made visible or made read only via iNotifyProperty changed methods in the screen code.  I also use a lot of custom modal windows, message boxes etc. on the screens.   Not sure what else to tell you as far as a repro, sounds your test project and pc setup is getting pretty close.  I can't share my project due to work restrictions, although I wish I could.  Did you happen to use an external db located on a different server?

    Those that are having similar problems are describing the same type of scenarios involving lots of queries, so something has to be going on with the queries in update 2.  I have used LS since beta and have not had this issue until Update 2.  I have done full VS uninstall/reinstalls as well.  Hopefully we will get to the bottom of it soon.  Thanks again.

    Friday, May 24, 2013 2:33 AM
  • Hi Matt,

    I'm on update 2.  Screens still take far too long to draw, and I don't see any difference between the same app side-by-side built with update 2 and the non-updated version.

    I don't think the delivery of the data is the main bottleneck.  This is a 2-tier application, btw.

    I'm also seeing the same design-time problems.  When I add an item to any screen in the designer, there is a pause where the CPU jumps and VS is unresponsive.  This varies from a few seconds up to a few minutes.  The more complex screens are the worst, almost to the point where you give up and close/reopen VS (but you know the same thing will happen again).

    But for me, the performance of the client is the biggest problem - this is what my users complain about, I can live with the design-time speed, albeit it's annoying as hell.


    Free Visual Studio LightSwitch extensions: Elyl's Extensions


    • Edited by ElylV Friday, May 24, 2013 12:54 PM
    Friday, May 24, 2013 12:49 PM
  • Hey Ely,

    I'm still checking out the Design time performance issues people have been mentioning. For your runtime perf issues have you checked out this: http://blogs.msdn.com/b/rmattsampson/archive/2012/12/28/lightswitch-performance-tweaks-anyone-can-do.aspx

    There are a few areas that are common problem areas for Perf (like Inactive "tabs") that I go over in the blog.  It's a general high-level overview.  The most telling thing would be to run a tool like Fiddler (http://fiddler2.com) and see how much data and requests are being sent over the wire (the request size and the # of requests might be interesting).

    Obviously, if you can share your project out that is helpful, or create a simple repro. 

    Another good way to raise awareness is to log a bug on Connect (I promise we look at these :)) - http://connect.microsoft.com/lightswitch


    R. Matt Sampson

    Friday, May 24, 2013 1:27 PM
  • Excuse my 2 cents but I too was having significant performance issues with Lightswitch until I installed Update 2, and now the long delays are a thing of the past.

    Whatever it is that you guys did to update 2... Thanks for doing it. :)

    Friday, May 24, 2013 7:26 PM
  • Jyuma1, are you saying design/dev experience is better in update 2 or runtime performance is better?  I agree that runtime performance is better, but still not good enough.  dev experience is far worse in update 2.  If you were refering to dev exerience being better, did you upgrade the project to LSv3?  Do you have a large datasource?  Screens with tons of queries, params, and local properties?  Just curious.
    Friday, May 24, 2013 8:29 PM
  • Hey Hessc - I've tried this out, discussed with others on the team, but not able to reproduce anything like what you see.  Honestly at this point, I'd have more luck researching the problem if you could make some kind of project that reproduces this available to me to look into.

    -Thanks, Matt S.


    R. Matt Sampson

    Tuesday, May 28, 2013 6:52 PM
  • Matt,

    I will try to make a repro as soon as possible.  Or maybe one of the others that is reporting this is able to send you their project.  Mine is locked down due to work restrictions.  Thanks.

    Tuesday, May 28, 2013 6:57 PM
  • Hi again,

    I somewhat fear that this thread is dying out. In my case the wait for a screen designer to accept the first change can be 10-20 minutes. As others have stated the wait seems proportional to the complexity of the screen.

    I should note that all fields are using the localization feature.

    Please feel free to contact me for access to a project showing the symptoms - via RDC or something like.

    Best regards

    JensBo

    Friday, June 28, 2013 11:01 AM
  • Would it be possible for you to zip up your project and send it to us?  Nobody here has been able to reproduce the long waits that are being reported in this thread, so a project that does it consistently would be a huge help.
    Friday, June 28, 2013 8:13 PM
  • Try the VS2013 preview, let us know if that resolves your issue.

    The preview fragments the lsml at both the screen and data entity level.  This should resolve your issue although not production ready, at least you will know there is a solution on its way, which I think was the original question of the thread title.


    Johnny Larue, http://www.softlandingcanada.com


    • Edited by John Kears Saturday, June 29, 2013 2:44 PM missed word
    Saturday, June 29, 2013 2:43 PM
  • I am planning to try VS2013 soon and will post back with results.  I still have very long waits as of update 2.
    Saturday, June 29, 2013 3:21 PM
  • You will be disappointed, as my test, vs2013 even makes the design-time performance worser.

    Monday, July 1, 2013 11:57 AM
  • That's not good.
    Monday, July 1, 2013 11:05 PM
  • + 1

    Query Designer becomes really slow...

    Any help with the visual studio extension of ryan? How do we implement this?

    Tuesday, July 2, 2013 6:32 AM
  • hi!

    just my humble opinion (i'm self-learned inexperienced programmer, maybe the one for who this product was intended in first version):

    i don't like this policy of upgrades, similar stuff happened with v1, then v2, v3 - all of them not complete with bugs (sl part and unfinished html client), now v4 and new visual studio is around corner..too fast..

    i start a project, come to half of finish stage, and BANG! new version with new features with new options with blah-blah-blah is available.. great!! except that some things are not compatible (like devexpress reports in example, etc.)..  guys, come on, this really have no sense, i know that some of you are really "masters of trade" and literally have everything in little finger, but i believe that for most of other users this became little frustrating, work with "unfinished" (maybe too harsh word for it) product and put all our nerves on plate..

    don't know, i'm little tired of this product.. like it was said in some other threads, this product is great and (maybe) have great future (i guess you'll never know with Microsoft), but with this "upgrade" and "new version" politics, sorry to said - this drives me nowhere..

    cheers for now..

    Kivito


    Nobody expects the Spanish Inquisition! (M.P.F.C.)

    Tuesday, July 2, 2013 6:56 AM
  • Hi Andrew,

    I am not allowed to send the project but if you (by use of teamviewer or similar product) connect to my machine you are welcome to watch and possibly debug.

    We have quite a time difference but I would be available any time.

    /JensBo

    Tuesday, July 2, 2013 7:26 AM
  • Andrew (or any other)

    Any news here? I am running the Update 4 RC, but the design time performance has still not improved (10 to 20 minutes "not responding" on first edit in a screen designer).

    As mentioned before I would welcome anyone from Microsoft (possibly the Danish sub which is very nearby) to have a look at my machine on which the problem is consistent.

    Best regards

    JensBo

    Wednesday, August 7, 2013 6:57 AM