Your Development & Design Resource
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:
- Created a Computed Text instance on the main form.
- ... with the following formula:
- 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!