Share via

LightSwitch – 10 Performance Tweaks Anyone Can Do

  • Article

 

“HOW can I improve performance in my LightSwitch app?” – is a question that pops up in the MSDN Forums frequently enough (like here and here).

I’ve got some basic tips below that show how to make some some simple tweaks to your LightSwitch app that could improve your performance:

1) Non active "tabs"

If you have non active “tabs” on your screen, you should know that they still execute HTTP queries over your network to retrieve data. . One work around for this is to break out your tabs into separate screens.

2) Data columns you don’t care about

IF you have control over the data model, consider breaking out columns that you don't show on the screen into separate tables, and then create a 0..1 relationship with that table. For example, let's say you have a Customers entity that has a picture of the current customer, but you don't show that picture on the screen. That picture data is still going to be requested and thus hurt performance. A way around that would be to refactor the data model and place the picture data into a separate table that is related to customers by a 0..1 relationship.

Reference properties on your entities are another piece of data that can slow down your performance. If you have reference properties on your entity, but you don’t care about them, then consider removing them from your screen

3) Computed Properties and Validators

Avoid performing queries in computed properties and validators. Or consider "persisting" computed properties IF it makes sense (I do just that on my blog here: OData Apps In LightSwitch, Part 1)

4) Editable Grid Screens vs. List and Details

As a general rule, List and Details screens perform better than a Editable Grid screen.

5) A bit more advanced IIS Server tweaks

There are other options that you could consider on the IIS Server (assuming there is one). Enabling dynamic compression could be helpful if you have CPU cycles to spare on the IIS Server, and you suffer from limited available network bandwidth.

Having your data tier machine (for example the SQL Server) and your IIS Server on the same machine, if possible, would obviously reduce network latency issues.

6) Screen methods

If you are doing filtering of data in one of your screen methods, consider doing that on the server tier if possible. That way, by filtering the data on the server side, you can reduce the amount of data that is sent across the network since that additional data that you filtered out won’t get sent over to the client now.

Another one to be careful of is the Screen_InitializeDataWorkspace() method. Keep in mind that any code you run in that method has to complete before the any of the screen queries will be executed. It can be a bit of a bottleneck if used incorrectly.

7) Profiling

Don't be afraid to use profilers to profile your client, and middle tier logic. Use SQL profiler to analyze the queries you application is executing. Use Fiddler to track the number of middle tier requests and the response sizes.

8) Load Testing

Load testing is a great and easy way to get some data on how your LightSwitch application will perform in the real world. Visual Studio Ultimate has some great tools for doing your own load testing (and there are a number of 3rd party tools as well). Also see my friend Saar's post about Load Testing with LightSwitch Apps.

 

9) Giant screens with lots of data 

Probably obvious by this time, but keeping your LightSwitch screens small as possible, and not too complex will almost certainly help you avoid many a performance issue.

10) Queries (the messy ones)

Queries can be difficult to get “right” sometimes. They can be messy and just slow everything down. That is a blog post by itself, and fortunately my smart co-worker Beth Massi has already written one Smile - check it out - LightSwitch Tips & Tricks on Query Performance.  

That’s it for now. We’ve been working on some awesome stuff here at the Fargo office, and I’m looking forward to blogging on that shortly. But first I’ve got some more testing to do.

Let me know if this helps (or not).

Thanks a lot – Matt Sampson Martini glass

Comments

  • Anonymous
    January 10, 2013
    Thanks for the tips - as I posted in the forums (one of the links at the top of this page) for me the main performance problems comes from the datagrid (5 in a screen with some columns and rows) what are you working on? (awesome stuff :-)) robert

  • Anonymous
    February 26, 2013
    Hi Matt, We were having performance problems with a app I developed for a client. To start with we though it were the computed columns that were causing the problem so I manually did the calculations on the columns. the search screens now definitely load quicker but I've noticed that the more you leave that screen and go back to it the worse the screen switching gets. For example. My client has a search screen that shows all complete invoices. It shows, Id, Customer Name (related data), Invoice/Credit, Nett Amount, VAT and Grand Total. There is an add button I put on this screen for them to easily create new records. As they create new records, it takes longer and longer to re-display that search screen to the point that the system can hang for two or three minutes. I have far more information on this behaviour and if you would like to know more, please feel free to get in touch. Paul Pitchford (@paulpitchford)

  • Anonymous
    May 22, 2013
    Hello, Thanks for a great article. I'm puzzled by #1 though. I thought Lightswitch didn't create controls or load data until they were needed. Howcome it loads data on inactive tabs?

  • Anonymous
    May 23, 2013
    Mr. Yossu - Sadly, I don't have a good answer for you.  LightSwitch Silverlight Client does indeed load data for inactive tabs (you could verify through Fiddler -http://fiddler2.com/) if you want. Wish it didn't but it does indeed. There isn't an intentional reason for it.  The HTML Client at least doesn't do this.  I'll follow up though and see if we can re-visit this issue on our team.

  • Anonymous
    August 02, 2013
    Useless. This is all pretty self-explanatory. Unfortunately, Lightswitch just simply takes forever for simple data that it shouldn't need to. Disappointed.

  • Anonymous
    June 18, 2014
    The comment has been removed

  • Anonymous
    September 05, 2014
    I have the same issue. I have a list of courses with a related Teacher. there is a picture property on the teacher. When I load the list of courses, It "expands" the teacher and although I just need the name also the picture comes over the wire. I hoped disabling "Display by Default would do the trick... Is the only way to avoid this, to create a ria service???

  • Anonymous
    September 08, 2014
    Hey Bert - I'd try using the LightSwitch HTML Client instead of the Silverlight Client if you feel comfortable with that (there are a number of HTML Client tutorials online now for LightSwitch) Otherwise a RIA Service as Andreas mentioned seems like a decent solution (though a bit more advanced)