Guest Editorial

Digg This!

Page 2 of 2   « previous page

• Compile your application into "machine code" if you perform a lot of looping operations in your application code. The performance gain may be up to 4,000% (depending on what operations you are performing)!
• Use the DataWindow to generate HTML, XML, and JavaScript. It's normally much more efficient than hand coding it yourself.
• Never code any working code in either a Constructor or Open event. Always create a PostOpen or PostConstructor event where intensive initialization logic is coded.
• Try to use continuous feedback mechanisms where long processing tasks cannot be avoided. That could be in the form of a simple progress bar or using a polling technique in a Web page to let the user know when something has completed.
• Break complex transactions down into small steps and guide the user through the sequence while confirming each step as you go along (continuous interaction gives the user the impression of excellent response time).
• Retrieve only the information needed to satisfy the current transaction. For example, if the employee address is required, do not select employment history, pension information, current projects, etc., just because you think they make take that route next in your application (don't laugh, I've seen that coded).
• Don't save up multiple row updates. Update each row as the user changes the data and focus. This also helps prevent deadlocks - however, you may have to change your database design to accommodate this technique.
• Use "dirty" reads to force "no locking" operations for read-only transactions. This instructs your DBMS to bypass tracking row, page, and table locks, which is a very CPU-intensive operation.
• In EAServer, use "Connection Caches" tuned for their functionality, for example, a CC for BLOB processing where packet sizes can be optimized for heavy DataStreams.
• Update your software to the latest versions to help gain access to new O/S features and performance/stability options.
• Set up a separate a "performance and stress testing environment" that mirrors your production environment as close as possible.
• Use products like WinRunner, Robot, JMeter, etc., to drive both thorough functionality and load testing on your application system's various components throughout the SDLC.
• Sort your data on the client or application server. Adding an "Ordered By" clause on your SQL forces the result set to be written to disk.
• Never name a stored procedure beginning with "SP_" as it forces an MS-SQLServer or ASE DBMS to access the "Master" database each time (weird but true).
• Use PowerBuilder's multi-threading features by utilizing the SharedObject methods.

I hope you are able to use some of these suggestions in your next development (re-factoring) project. There are a lot more things that I could cover, but not for this short editorial. I just wanted the reader to get a feeling for some of the considerations you need to address - that the average application will face. Even for smaller applications it can make a difference with the longest transaction completing in 1-2 seconds versus 15-30 seconds. Last, but not least, if you get the chance to talk to your local university or college, ask them to reinstate or develop a "Designing for Performance" course and introduce it into their curriculum (like the good old days) instead of buying more hardware. I would suggest to vendors and educational establishments that holding contests that award prizes for completing a transaction in the fastest time, with the least amount of code, with the least amount of I/O, etc., is a really "Cool" idea!

Page 2 of 2   « previous page