|
PowerBuilder good programic practices :
Use static function calling convention instead of dynamic functions.
The dynamic calls are flexible but affect performance, additionally the dynamic calls are not verified by compiler
that may lead to runtime errors.
If you need call a function dynamically it is better to declare virtual function in ancestor object and then call one
from descendands.
If the variable doesn’t change in application then declare them as constants in none visual user object.
If your functions receives many parameters like string, blob, date, etc. then pass ones as READ ONLY.
Passing parameters using READ ONLY pass value without making a copy of the data.
Use local variables for fast performance and avoid global variables. Take scripts as short as possible for faster compilation.
If you reference objects using "dot" notation try decrease number of execution checking (look at example)
by using the DWObject object reference:
DWObject ldwo_dw
ldwo_dw. = dw_details.Object.v_first_name
ldw_dw.visible = 1
ldw_dw.background.Mode = 0
ldw_dw.x=12
ldw_dw.y=12
You can also modify DataWindow properties in one pass using DW.Modify function.
Modify garbage collection default interval (0.5 second). Use following function to managing garbage collection:
GarbageCollect()
GarbageCollectGetTimeLimit()
GarbageCollectSetTimeLimit()
To verify when and frequency of the garbage collection mechanism run trace and profiler (see the section )
TreeView -> don't populate all levels of the tree view. At startup populate only root and then use ItemPopulate
event to insert items in child branches.
Disable redrawing screen using SetRedraw(FALSE) in case a list or tree view is populated
If end user complains that the screen opens very slowly then check the OPEN window event. If some initialization actions are performed in OPEN event then move them to UE_POST_OPEN event (look in PFC libraries). The event should be posted, the script will be called after the screen open so from end user point of view the window opening will be faster. So remember the rule that window won’t display till OPEN event is finished.
Additionally don’t do time consuming actions in constructor event.
The dynamic libraries (*PBD) should be less than 800k. The PowerBuilder runtime environment access entire file to get definition of a single object. During development the larger libraries (*.PBL) also slower performance.
For intensive operations like bitwise operations, string manipulation, text files modification create external functions written in native C/C++ . The PowerBuilder interpreter is very slowly in listed areas.
If PowerBuilder application tuning and database tuning doesn’t improve performance then start think about distributing application using Multi-Tier Application Partitioning. The multi-tier environment are build with application servers. The most popular architecture is the 3-tier partitioning. The business logic is stored in middle tier in application server’s components. The middle tier allow to encapsulate complex logic in one place that is available by many applications (not only written in PB). The middle tier is better scalable has heterogeneous support. The application servers allow to cache data, connections or transaction pooling. For more details about n-tier environments see document . The additional advantage of the n-tier environments is that the most of the application logic is executed at server site therefore upgrades concern only some servers instead houndreds of client workstations. The application servers support asynchronous processing that allows client to continue with other tasks.
If retrieving DropDownDataWindows cause performance downgrade then redesign DDDW and retrieve only the columns that are really mandatory. You can avoid retrieving list to DDDW using joins in master DataWindow. Most applications use DropDownDataWindows for displaying dictionary lists that doesn’t change frequently. By choosing the lists that are static you can populate them with data and store data with DataWindow definition in dynamic library - this approach reduce number of SELECT statements issued from application.
Minimize repeated retrievals the same data, try to cache data and/or share them with other datawindows.
Use asynchronous database access . In this approach the most processing is executed in background at database server and end user receive control immediately . If the action can be canceled then allow perform it via GUI. During asynchronous calls you will need multiple connections (transaction objects) at potential concurrent section, if most of actions are performed in concurrent sessions then use PowerBuilder connection caching functionality.
Your screen consists of tens of objects and opening is slow?, think about using DataWindow instead of many separated controls. The DataWindow are more compact and faster, additionally in this case you add more power for the controls
.Use applications provided with PowerBuilder to locating the cause of performance problem. Use tracing and profiling utilities to store statistics about number and time of code execution, number of created objects, garbage collection and etc. If you are interesting only in SQL statements that are send by your database then use trace functionality for PB native drivers and ODBC drivers.
You have noticed that application generate to much network traffic ? Are you database programmer expert? If your answers are Yes then instead using UPDATE, DELETE, INSERT , SELECT statements use the procedures stored on database server.Of course in this way the development process require much more coding on database server but you receive some advantages like: reduced network traffic, use power of the database server coding futures, the procedures are stored in compiled form, you can validate data on server and return business logic errors.
Additionally the server side procedural language is the most powerful in database modifications, don’t try replace them via logic embedded in PowerBuilder GUI application.
For database tuning see document about Oracle tuning.
|
