Question

We are developing desktop application in vs2008 with winforms and sql server 2008.At present, we make lot of dbase calls(linq to sql) on form load, so this make the application real slow.One option is to load all the data required at the start of application load, and store it in a cache(just static collections).What other options we should look at? Are there any available guidelines available online?

thanks

Answer 1

Several answers here seem to be heavy on assumption and gloss over the most important point:

• Before you can usefully optimize anything, you need to find out what is slowing it down.

Use a profiler. A good free one is EQATEC. Or if it’s really, really slow, just step through the program. Also use the SQL Server Profiler to see what’s going on with the queries themselves.

The problem may not be one of caching at all. It may be a poorly-optimized database. It may be a slow network connection. It may even be something totally unrelated in your code. There’s no way to know for sure unless you check.

Having said that, if the problem really is simply having “too many” database calls, there are a few approaches you can take that won’t cause a major spike in the application’s load time:

• Cache data the first time it is used;

• Switch to using Stored Procedures that return multiple result sets (using IMultipleResult – example here). This requires only one round trip for several sets of data. Or, if you can, combine the results into one query/result, if the data that you are currently querying separately can all be JOINed together.

• Perform your data-access operations in a background thread (i.e. using BackgroundWorker). Often the problem isn’t really the actual speed, just the fact that you block the UI while it’s happening.

• Start your application right away without pre-loading any data, but immediately start pre-loading in a background thread. Add some synchronization code so that if the user does something that requires the data before it’s fully loaded, it will wait for the preloader to finish.

• Use an abstraction layer, such as a WebService, that “lives” very close to the database server and isn’t hurt by a large number of round trips. This can then supply all the data relevant to a single UI screen/form.

All of these are complex options that may require a major overhaul to the application architecture. Your life will be much easier if you can simply optimize a few queries with indexes, or combine multiple queries into one. First try to find out why – and I mean specifically why the application is slow; then and only then should you be seriously considering any of the above options.