17.7 Performance Issues

Testing and Balancing Across Multiple Platforms

Different operating systems are good at doing different things.

For example, an IBM i is very good at doing database I/Os and Windows is very good at CPU intensive operations like SORT_LISTs.

You cannot sensibly estimate what an applications performance will be like on one platform by testing the application on another platform.

It is your responsibility to find the right balance between differing hardware platforms. Your application design must consider how the platforms are different and determine how to best utilize the specific features the platform has to offer.

Amount of Information in Panels/Dialogs/Windows

Do not overload screen panels, dialogs or Windows.

For example, a screen panel containing 100 fields may be slower to present when executing under Windows compared to an IBM i.

"Drawing" time in advanced graphical environments is directly related to the amount of information (i.e. number of objects) in the windows.

PC, Desktop and LAN Based DBMS

Generally IBM i developers form their perceptions about the speed and methods by which they can access a database table from their IBM i experiences. Unfortunately this may be the worst possible place to gain these perceptions.

The IBM i is a multi-user database machine. Its database access is very fast and relatively little attention has to be paid to the impact of DBMS requests on the system or other users.

However, as we move more and more towards PC, Desktop and LAN based DBMS, developers may have to alter their perceptions and change their habits accordingly.

This is a subjective area, and PC DBMS vendors may dispute this, but development experiences so far have indicated:

So, in any context where you are using a PC based DBMS, please think about the following before you implement an application:

Disk Space Considerations

When using Visual LANSA to develop and test IBM i-based applications, you should not keep source or objects that are not required to execute the application (e.g. .C, .H, .STG, .DEF and .MAK files) on your PC. By removing these files, you will substantially increase the amount of available disk space on your PC.

If you are creating stand-alone applications for Visual LANSA, you should also consider compiling the final version of your programs without debug enabled. Compiling without debug will further increase available disk space.