Troubleshooting slow databases - the UI

09/28/2006 02:46 PM by Chris Toohey

We've all been there (especially consultants) - you're trying to increase the speed and performance of a horribly functionning application that was written circa 1999 and you're looking for a quick win. The database itself functions, albeit it's bloated and not designed very forward-thinking... but it's functional - just not very fast! So, you immediately start ripping it apart to see where you can trim it down for a v.+1 patch.

I ran into this myself just recently - my new client has their most critical business application... and it takes in upwards of 5 minutes to open a single document.

So I says, "Self... let's look under the hood!". And what I found was a pretty functional application that was more or less bogged down by it's UI. That's right, painting the screens was one - if not the biggest - issue resulting in a pitifully slow, business critical solution.

So - to troubleshoot (read: here's a hint to those who need to troubleshoot), I did the following:

1. Created a Computed Text instance on the main form.
2. ... with the following formula: @Text(@Now)
3. Copy and Paste this throughout the tabbed UI

When I launched the form the next time, I could literally see the lag in painting the screen represented via the timestamps visible as I went from tab to tab on the form. I could see the 5 minutes of lag, and more importantly, how that 5 minutes was spent.

I'll put a few more of these tips up here... a few things that I did to get that application that launched in 5 minutes to launch in under 30 seconds from the slowest of machines over the company WAN. There's a few more nuggets out there that I think will help us developers always looking to shed seconds off of loadtimes and functions!