Maestro*Liaison February 2007
Return to News CenterPerformance is a constant concern
Improvements to a software program are usually made in several steps. Initially, the types of functions to be added must be determined. Next, we must thoroughly analyze the desired elements and describe them in detail. We must also anticipate the repercussions of changes on the rest of the system and on users. Finally, we debug the requested modifications, test the application and document it.
An element that is often neglected throughout the process is the performance of the new application and its effect on the performance of the system as a whole. It is easy to overlook this dimension because the objective is usually very specific, without any real possibility of compromise. Additionally, changes normally only represent a minor additional demand on equipment resources. However, over the long term, an accumulation of small tasks can have a significant impact on the response time of programs.
One example could be programs that manage system screens. This group of programs ensures that all screens are displayed correctly, based on the parameters determined when the system is installed or, in some cases, by users themselves. These parameters include basic elements, such as the size of the window and its position on the screen, but also more complex elements, such as the working language, display colours and fonts, and very specific elements, such as the display of value descriptions that are displayed in drop-down lists. This group of programs is also responsible for the overall processing of grids, whether for selecting columns to be displayed, the labels for these columns, or for the display order of columns in search grids.
Over time, an increasing number of functions are added to this group of programs. Since they are an integral part of the startup of each option of the system, this allows us to expand the functions on all other screens of the system through custom development, without the need for additional programming. After all, it would be unthinkable to change each of the 1,100 screens in the maestro* system one at a time. However, since this set of programs is executed automatically on startup for each screen, it is possible that general performance will be affected. At this level, the challenge for the development team is primarily to achieve a balance between function and performance. We must continue to develop the functions in the screens, but without forgetting to determine how far we can go without running into the technological limitations faced by our customers. To complicate things further, this balance is a constant issue with users continually improving the performance of computer equipment. Now you can understand why performance management is not easily controlled.
Recently, during development of version 3.01, we completely changed the display of all screens. Comments about the new appearance of screens was very positive, but these changes had repercussions on the overall performance of programs, and we noted that the display of some screens was slower. This problem occurs primarily on screens that contain a lot of information, such as the various consultations or complex management involving employees or projects for example.
Another reason for the decrease in speed is the volume of data. Since version 8.5, the performance of the SQL engine of our database provider (Pervasive SQL) has improved significantly. We are using it to a greater extent to access data when an increase in performance is possible. This allows us to perform certain filtering or sorting operations on the server rather than on the workstations, resulting in a significant increase in performance when high volumes of data are involved.
In version 3.02, for which development just started, we will attach greater importance to the performance of our programs. We are confident that we will continue to improve all of our applications, while maintaining acceptable response times. The ultimate goal is obviously to have rich, complete and configurable screens, with all of the desired functions and instant display speeds. Quite the challenge for our programmers...
Version 3.02
As mentioned earlier, we recently started development on version 3.02. This
version will be the logical progression from version 3.01 and will not have any major structural
changes. This will allow us to continue with general development of the application, and move ahead
with significant changes requested by some of our customers. This version will also allow those
who want more stability to use version 3.01, which will soon become the current version of
maestro*, which will signal the end of fixes for version 2.04.
Michel Fisette, Director R & D 01/02/07
