Performance Enhancements with DBServer and DataWindow (part 1)

Introduction
For those who have been following various VO version releases, it is quite plain that the GUI classes are finally coming of age. Beset with problems in VO 1 days, the GUI classes gave rise to the hugely successful ClassMate suite and ReportPro but converting to these 3rd party products is a serious commitment and not for the beginner. So most of us are “trapped” into using the native VO GUI classes… but are they all that bad?

Well, the short answer is no. The VO GUI classes are essentially a late-bound library, designed to be all things to all people. They offer maximum coding flexibility and are specifically written to offer the developer a solution with the shortest number of lines of code. Compared with CM solutions, this is certainly true. However, weakly typed and late bound code has a price for this flexibility: performance.

Under a great many situations, this performance penalty it simply too small to notice, but once we deal with datawindows holding 100 controls and servers with 1 million records, we do find some issues with depressing performance characteristics. However, our VO fathers have given us the SDK, the complete source code to the GUI classes and armed with this, there is nothing we can’t tackle in the name of efficiency. The aim of this paper – which is presented to you in several continuous parts - is to demonstrate some of the more obvious and beneficial changes you can make to your applications. We will cover some of the theory in detail and present you with some coded solutions. When you make use of these techniques there will be no doubt that you will see measurable gains.

Of course however, there must be a warning (…or else this wouldn’t be VO!). If you have windows with sub-second response times, apps which start and load immediately and browsers which pop up instantly then you are in no need of these pointers. As with all things, we try not to fix something until it is proven to be broken or we apply measures to areas we know might become bottlenecks in the future. There is never any point in applying change for change sake. If something can be done quickly, in native code, then this is what should be done. Please note that throughout this series of documents, SDK code extracts have often been abbreviated. To use this in your code, it is recommended that you purchase a copy and investigate the methods fully for yourself.

What is “Performance”
Before we begin, I must prevent one misunderstanding before it occurs. Performance is not just about speed of execution. It is also about reliability and maintainability and I judge these two issues to be infinitely more valuable than “speed” performance on its own. This paper will deal mainly with physical performance enhancements, so let’s briefly discuss the other two. In any event, as we shall see in our buffered server example later, one can and does lead to the other.

Reliability
Reliability comes in many guises. Largely we are concerned that users can achieve the desired level of productivity from our application. What are the common needs?

• Consistency – It is important that a “History” button works the same way everywhere, that repeated calculations provide the same result over the same data (don’t laugh!), that open/close/execute actions are the same everywhere. The buttons will have the same name in all windows and do basically the same thing. This equally applies to “Save”, “Refresh”, “Edit” and so on. You will write much less code, because the bulk of processing can become default and thus placed in a header class referred to with SUPER. Editing becomes easier and debugging becomes easier.
  
• Predictability – Having drilled down through a set of menus to get to definition tables, the user knows he can expect to be able to edit, add, delete or print, or that all the definition tables can be found under “Maintenance”, that control orders are in place with logical tab sequences to aid data input. This not only helps the user, but it helps you the developer.
  
• Accuracy – That your data output is 100% correct all the time.
  
• Practicality – You are adding an invoice and want to choose a client not yet in the debtor database. So, do you have to quit this and navigate back through a dozen menu choices to add the new client and then find your back, or, can you add the new debtor in-situ (on the same edit window otherwise used) and then continue unimpeded with the invoice?

Maintainability
So you have this 300,000 line app with 24 dll’s and 3 exe’s and now the user needs you to add 3 new fields to the client server. This has to go out to 400 sites where everyone already has two years of data in their DBF’s. A problem? Of course not. Not, of course, if you designed the app appropriately in the first place. The coding style to adopt will align closely with our reliability goals, so how do we achieve this?

• Documentation - … And not only the user manuals. Of greatest importance can be data dictionaries and flow diagrams. An invoice is linked to how many other servers? What are the relationships into client records or the bank book? It is quite a relief three years later to pick up a listing of the servers relevant to a job and to have in front of you all available orders and expressions. But you must document as you go. It never happens in arrears.
  
• Code Comments – I guess this is a popular theme, but no less relevant for its ubiquity. There is never a need to explain the obvious, nor is there any need to write a book in every method, but as we will see shortly, proper naming conventions take away half the problem. A few well chosen words to explain formula or events are important. Also, if you have come back six months later and changed something, stick a date there at the change. It helps put a perspective on what has changed and why.
  
• Naming Conventions – We all know about Hungarian notation, so I don’t need to go into this. However, I must make one point that is very relevant to our later discussions. Name your variables and methods as accurately as possible. And don’t be afraid to use all the letters of the alphabet. EditConsoleOptionsWindow{} will be a lot more useful than EdConWin{} in two years time when you come back to do some work (for example, was that EditContactsWindow{} ??). Likewise for variables: dwOpenWinCount is a lot more useful when reading code over dwCount. How often do you see “n”! (especially as an array index). What about nArrIndx or even nArrayIndex? VO 2.5 has a template completion facility, so you never have to type this stuff, but it does make reading code a lot easier. Closest to my heart, the names of controls and variables should, if possible, match server field names for immediate identification. We discuss this in more detail later.
  
• OOP Design – I am a strong advocate of functions and globals where it makes sense to use them. However, the closer you are to the theoretical OOP model, the easier it will be to modify or expand your code. The aim of OOP coding is reduce the overall coding effort. Turn your data models into objects and manage collections of actions (ie methods) and properties as an object. Your reliance on arrays will reduce and modifications will become simplicity. We will cover some of this later.

Summary
Performance is not just about speed. It is as much about coding design and implementation. Having said that, from here on in we are going to concentrate speed enhancements with a lot of coding samples and use the tools we are developing to analyse our progress. We must, however, keep reliability to the client and future maintainability for ourselves as goals in tandem with response time initiatives.

Please stay tuned to www.sdgn.nl to read part 2 of this article!