It may not be economically feasible (or necessary) for you to throw money at speeding up applications. Spending a certain amount of money on speed may be expedient and eventually even necessary, but it shouldn't be our first choice as analysts or managers. Too many hours are spent working up cost justification analyses and AFEs (Authority for Expenditures) that could have been spent on actual repairs.

You could finance the Sys Admin people upgrading your UNIX server at an often-huge cost or get speedier desktop machines for your users (implying faster solitaire). You could even get a contractor to come in. While all these will probably speed things up, you could roll up your sleeves, put on your work boots, save the company some serious bucks, and win the adoration of your users as you turbocharge their apps.

The following three ideas cost only your time and intellect. The combined effect of these alone can result in a significant performance increase.

Your Mamas and Your Sisters
Don't Work Here
This sage advice was given to me while contracting with a research firm in Huntsville, Alabama. It was in reference to empty pop cans, but that's beside the point - which was to clean up after yourself. It's vital that we do our house cleaning and examine the timing of our user complaints.

Does the application seem to slow down more as the day wears on? This typically means that you haven't done the necessary housekeeping. There is a memory leak in your code. You can fix this by looking for several easily correctable mistakes.

Those of you using a version of PB previous to 6.0 may have trouble if you aren't doing the proper housekeeping. There are some simple maxims you should always remember: if you created it, destroy it; if you opened it, close it; if you connected, disconnect. This may seem an oversimplification, but it will serve you well. You also need to go ahead and upgrade to a supported version of PB.

Post-6.0 PowerBuilder will employ Garbage Collection and clean up most of the orphaned or circular references in your code. There are areas that this doesn't affect, however. Sybase has well documented that they don't Garbage Collect on Visible, Timing, or Shared Objects. Also, if you have posted events or functions, they won't be G-Collected until after the event or function has run.

The Realized Pain of the Few vs the
Wails and Moans of the Many...
As the number of users and data grows, practical changes must be made to accommodate scale. It's vital to examine where in the course of data entry or the job stream you're doing the heaviest processing. Is every user sitting through error checking?

I support an application that had a lengthy process doing extensive error checking. The process was positioned such that a one hundred-plus people had to watch a spinning hourglass or (my favorite cursor) the burning dollar bill while it ran numerous times daily. After examining the functionality involved, it became clear that I could move the errror checking into a different area and still effectively suppress bad data entry. I moved that checkpoint to a place where a small group could confirm the validity of the information so the large group never had to see it.

This change gained hours a day in user time, and we didn't lose any quality assurance.

Too Many Stops Along the Way
How many server hops is the application making in the course of touching the network or the database? In the course of testing applications, I once found some users on a given floor were making multiple hops to get from their localized network to the servers where the database lived. This was awkward, but not a difficult task for the network people to correct.

They did some simple testing to check the jumps from my machine to the server using TraceRT, then went to the users and confirmed that they had the same problem. Once it was established that there were n-jumps to get to the servers, they began adjusting the connectivity to give us a direct line to the database server in question. This simple and inexpensive change shaved minutes off the Save process for deal entry.

And the Final Word
There are many ways to increase system speed and optimize your application. First, as a developer make every effort you can to ensure that your code is the best it can be, that your connectivity is not in question, that the DBAs have the database well tuned, and that you don't have any sloppy SQL. Then you can begin to look outward. You'll find that your users will treasure your efforts as they run their jobs in a shorter and shorter time frame.