locked
LightSwitch too slow? RRS feed

  • Question

  • It seems that the lightswitch application is too slow.
    Monday, August 30, 2010 8:50 AM

Answers

  • Hi,

    Performance is something that we are currently working very hard to improve post-Beta.

    Please give us some specifics of the areas that you feel need the most improvement.

    Thanks,

     


    Steve Hoag Microsoft aka the V-Bee
    Monday, August 30, 2010 4:04 PM
    Moderator

All replies

  • Hi,

    Performance is something that we are currently working very hard to improve post-Beta.

    Please give us some specifics of the areas that you feel need the most improvement.

    Thanks,

     


    Steve Hoag Microsoft aka the V-Bee
    Monday, August 30, 2010 4:04 PM
    Moderator
  • I'd like to give kudo's for your hidden implementation of caching lookup data (combobox or modal window picker). It's impressive.
    MicroApplications, Inc. -- Information Systems Integration and Custom Software Development
    Monday, August 30, 2010 4:07 PM
  • Thanks for your interest in LightSwitch! To help us understand more of your performance situation, can you provide the following informations?

    1. Is the IDE slow or the runtime application created by LightSwitch is slow, or both?

    2. Can you give me a summary description of the project including the number of tables (local and attached), number of screens, queries etc? Do you have many computed fields?

    3. If the runtime is slow, can you give me information on the deployment of the app? such as 2-tier,  3-tier desktop, or 3-tier web;  what database is being used, etc.

    4. Please provide information about the development environment, OS version, CPU, RAM etc.

    Thanks

     

    Monday, August 30, 2010 4:09 PM
  • I have been experiencing slowness in the IDE. I am building an application with about 100 tables in one database. Some properties computed (40% of the tables). I have not set screens and queries.
    Monday, August 30, 2010 4:26 PM
  • I noticed the same behavior and slowness in IDE. When you attach a database with more then 100 tables, the project is practically unusable. 

    I don't know if this will happen when you add the tables from LS interface. This should be tested.

     

    Regards

    Monday, August 30, 2010 4:37 PM
  • I have only 6 tables and about as many screens, but when I hit F5, it takes "forever" to build and load all the assemblies before the app is ready to go.  Makes code-and-debug very painful given how long I have to wait each time for the app to fully enter the running state.

    Performance within the running app seems fine to me, though.

    Monday, August 30, 2010 5:02 PM
  • Hi,

     

    generally LS is fast enough in intranet scenario (I can't test internet because of the silverlight version issue) in both IDE and runtime and having a few only tables.

    It is much fast when running on ie 8 and it is very slow when it runs on Chrome.

    There is however a few scenarios that LS is becoming very slow: when a collection that contains lookup columns is displayed in a list or grid. While the list with flat data is displayed fast enough lookup columns shows line by line very very slowly. Looks like for each row in the collection a query is running for each row and each lookup column to get the referenced column summary property - which I understand. This of course could be solved if I just don't include lookup columns in the displayed collection OR (and I think this is better) if there was a way to get a db view instead of a table as the source of the collection without missing the ability to navigate to Entity Detail Screen (maybe one to one relationship of table  and flat view that now is not supported due to the "same context restriction"?).

    The more I use it the most I like it. Great job LS team.

    Thanks

    Monday, August 30, 2010 6:45 PM
  • I've just created my first LS application and added a search dialog for a table with 45000 rows and 15 columns.

    The dialog runs, but everything (Searching, sorting, scrolling) is very slow. Much to slow for production use. Compiling the application in release mode seems to improve performance a bit, but it's still way slower regular ajax applications.

    The bottleneck can't be my database (equivalent queries in MSSMS run blazing fast), or the network connection (the database is running on localhost). It seems that Silverlight / Lightswitch is the problem.

    If you need any more info, feel free to contact me at adrian@lobstersoft.com . I am not sure if I will be monitoring this thread regularly.

    Thursday, October 7, 2010 7:10 PM
  • Hi Adrian

    Would like to understand more about the how much data are you displaying on the search screen -
    Are you displaying all 15 columns? what type of data is being displayed in these columns? What is the screen size?
    Lastly what is your machine config?

    Thanks

    Saurabh


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, October 8, 2010 1:29 AM
  • jsalichos wrote: "Looks like for each row in the collection a query is running for each row and each lookup column to get the referenced column summary property"

    The next beta will support including such lookup data in the original query for the row instead of having to issue additional queries, so it will be much faster.

    Steve

    Friday, October 8, 2010 5:14 PM
    Moderator
  • Steve,

    Almost everything i look for seams to be available in the beta 2. any ideas on approx timeframe when this will be available?

    Regards,

    - Kiran

     

     

    Friday, October 8, 2010 5:23 PM
  • Kiran, we're not talking about any release dates.

    Steve

    Friday, October 8, 2010 6:30 PM
    Moderator
  • Steve

    Unlike bbakermai I've not noticed anything great about performance and although I haven't looked at the caching implementation there is no evidence on the UI of much caching being used to help out performance.

    My app scenario is very simple:

    3 SQL Server database tables

    Category (Id & Description) - about 5 records entered

    Type (Id & description) - 2 records entered

    Incident(Id, FK_Category, FK_Type, Date, Count)

    I have created a screen for adding Incident records via a grid.  I'm using comboboxes to allow selection of the Category and Type.  The grid gets displayed quickly for entry of the first record.  When I click on either combobox there is a pause of a couple of seconds while the lookup data is retrieved.  Once the data has been retrieved it is cached in the combobox FOR THAT RECORD ONLY.  IE on that record if I click on the combobox again there is no pause for data retrieval;  however if I go to a second record and click on either combobox for that record I get the pause while data is retrieved.  From my observations I'm tending to conclude that:

    Each time the combobox is clicked for the first time on a given record there is a round-trip to the server to pick up the data.

    If the user entered lots of records (which wouldn't happen with my users as they would reject the application on peformance grounds straight off!) then each instance of the combobox probably has its own set of object instances which represent the same set of data - IE there are many object instances created for the same data.

    I would venture to say that the speed of data retrieval is <just about> acceptable for the combobox data if it is only necesasry to get it this way for the first record.  but for each and every record having to havea  2 second pause for each and every combobox selection is not a good UX.

    In VS I'm just pressing F5 and running - presume this is giving me a 2 tier desktop app.  I haven't managed to publish a LS app yet to run a release build.

     

    Pete.

     

    Saturday, January 15, 2011 12:52 PM
  • Steve

    Unlike bbakermai I've not noticed anything great about performance and although I haven't looked at the caching implementation there is no evidence on the UI of much caching being used to help out performance.

    My app scenario is very simple:

    3 SQL Server database tables

    Category (Id & Description) - about 5 records entered

    Type (Id & description) - 2 records entered

    Incident(Id, FK_Category, FK_Type, Date, Count)

    I have created a screen for adding Incident records via a grid.  I'm using comboboxes to allow selection of the Category and Type.  The grid gets displayed quickly for entry of the first record.  When I click on either combobox there is a pause of a couple of seconds while the lookup data is retrieved.  Once the data has been retrieved it is cached in the combobox FOR THAT RECORD ONLY.  IE on that record if I click on the combobox again there is no pause for data retrieval;  however if I go to a second record and click on either combobox for that record I get the pause while data is retrieved.  From my observations I'm tending to conclude that:

    Each time the combobox is clicked for the first time on a given record there is a round-trip to the server to pick up the data.

    If the user entered lots of records (which wouldn't happen with my users as they would reject the application on peformance grounds straight off!) then each instance of the combobox probably has its own set of object instances which represent the same set of data - IE there are many object instances created for the same data.

    I would venture to say that the speed of data retrieval is <just about> acceptable for the combobox data if it is only necesasry to get it this way for the first record.  but for each and every record having to havea  2 second pause for each and every combobox selection is not a good UX.

    In VS I'm just pressing F5 and running - presume this is giving me a 2 tier desktop app.  I haven't managed to publish a LS app yet to run a release build.

     

    Pete.

     


    Pete, the scenario that you had described, had been observed in other related posts, and the team had also mentioned they've done more changes in the data retrieval in Post beta 1 that is worth to wait for. My suggestion is, don't let it bother you at the present (still a Beta cycle) and look for more optimization as of Beta 2 and RTM.

    Hope this helps!
    ..Ben


    WPF/Silverlight Insider
    Saturday, January 15, 2011 2:45 PM
  • For Beta 2, we have done a lot of performance optimization both in the designtime environment and the runtime application. We implemted more caching when appropriate and optimzied data retrievals. The problem with the combo box should go away.  Let us know if you see any other performance issues.

    Thanks
    Yaqi Yang

     

    Saturday, January 15, 2011 10:50 PM
  • Great - that's really good news.  Looking forweard to the future!
    Monday, January 17, 2011 5:56 PM
  • I certainly hope that the performance increases that we see are also in the design tools.

    I am currently wasting 75% of my development time in LightSwitch waiting for VS to respond.   I am using Quad desktop boxes with 8GB RAM.

    I should be building 400% more software in the same amount of time.

    hehe . . . yes I am very grateful that I am not having to do the hundreds of hours of monkey coding that SL does for me.

    My wife and I watched The Social Network last Friday and my wife asked me why I can't code as fast as the PHP/Linux coders in the movie.  

    hmmm . . . one shot for every 10 lines of code?  Honestly, I can't drink that much - even as a kid that grew up playing music in bars.  

    While I was watching the same movie scene, I was wondering:  How much would 100-200 lines of PHP acutually accomplish?   Maybe 2-3 clicks in a LS Designer app.   How long would it take a PHP coder to accomplish what a single click does with RIA (many blessings to St. Abrams)?  With Beta 2 we will learn more about what happens behind the scenes with LS.  What we find out may be even more amazing than RIA and solving the mystery of M-VM-V coding.

    Monday, January 17, 2011 7:58 PM
  • Hi Garth,

    We focused on perf across the product cycle, so yes design time has seen improvement as well. You'll be able to have larger projects with less wait time.

    Steve

    Monday, January 17, 2011 8:30 PM
    Moderator
  • Had a quick to table utility that needed updated today, and decided that I would see how long it took in LS to create the whole project from scratch, compaired to added a column manually to our existing application.

    When I attached to the DataSoursce Wizard, I have been waiting for over 5 minutes for the list to show up of the object to pick from.  Our production database is made up of over 2500 tables, and a few hundred views.

    just thought you should know.


    Thank you!
    Friday, January 21, 2011 8:56 PM
  • NamoGuy,

    Thanks for the pointer. We know and it is fixed in the next beta (due to a perf fix in Entity Framework).

    Steve

    Friday, January 21, 2011 9:00 PM
    Moderator
  • Our production database is made up of over 2500 tables, and a few hundred views.
    Thank you!
    Wow, that's a tiny database... :-)
    ..Ben

    WPF/Silverlight Insider
    Friday, January 21, 2011 9:22 PM
  • Steven, thats awsome, can you give me a copy ? :^)  i wont tell if you don't

     

     


    Thank you!
    Friday, January 21, 2011 9:29 PM