Slow code – what are the causes and what can you do about them? Part 3
Previously we discussed the importance of selecting your programming constructs wisely, and managing your memory as efficiently as possible to reduce the threat of slow code. Applying some of these tips for database management will also improve application performance during production.
Database calls tend to be computationally expensive because they frequently go out to disk, and queries can take a lot of time to execute. An application making frequent database calls will be slow as the application pauses to write and retrieve data from disk.
Good programming practice involves creating an in-memory database object, using ADO.NET, LINQ, or similar technique. This brings the data needed by a particular routine into application memory. However, even this approach isn’t guaranteed to provide needed performance, particularly if database objects haven’t been constructed appropriately. In such cases additional data may have to be retrieved or the application retains data in the database object long after it should be returned to the database and the memory reclaimed by the system.
Databases themselves also offer caching, and it’s incumbent on the development team to work with the DBA to ensure caching is optimized for the application. While this may involve a measure of trial and error, database tuning at this point in the application lifecycle will ensure better performance during production.
Next, we’ll look at how to identify slow code in your application.
Blog article submitted by Peter Varhol, Technology Strategy Research