There are a lot of things ABL developers can do to improve the efficiency of their code. Writing efficient queries, managing record locks, and using the ABL Profiler to identify code that is taking the largest percentage of execution time are keys to improve ABL code efficiency during the development phase.

Manage data contention

When two or more users attempt to retrieve and possibly update the same data, the users may encounter data contention or what Progress refers to as record contention. ABL prioritizes data integrity through a combination of record scope and transaction scope.

For more information, see Transaction and record scope management considerations in Application Development with PAS for OpenEdge.

To avoid contention and bottlenecks when you access data Progress recommends being explicit in your code when managing record locking and transaction scope.

  • Use NO-LOCK on read-only record requests. NO-LOCK improves performance for other users who are able to update records without being blocked by unnecessary shared or exclusive locks. Add the SHARE-LOCK and EXCLUSIVE-LOCK options only when needed for data updates. Use comments to provide details to other developers about your record locking choices. For more information, see Record Scope and Read records with NO-LOCK in Develop ABL Applications .
  • Use the TRANSACTION keyword to limit the size of transactions. Add comments to clearly identify the transaction scoping strategy. Limiting the size of transactions helps limit the length of the record lock and avoids others waiting for record locks to be released. For more information, see Ensure a small transaction size in Application Development with PAS for OpenEdge.
  • Review the ABL triggers. Triggers are blocks of ABL code that execute whenever a specific database event occurs. For example, when you write a record to a database, a WRITE event occurs. For more information, see Best practices for ABL triggers in OpenEdge Web Paper: ABL Database Triggers and Indexes.
  • Use the compile LISTING on your development code, to review your record and transaction scope. For more information, see Generate a procedure listing file in Develop ABL Applications .

Write efficient queries

The ABL compiler is a rule-based optimizer that examines your queries and applies a series of rules to the query to determine the index to select for retrieving your requested records. The rules that the compiler uses are eliminations rules. The compiler looks at all indexes and selects an index by elimination. The compiler performs a pre-pass to eliminate indexes where the the first field in the index is not in the search or sort criteria. An index that may have a second field mentioned will not be as efficient as a leading component. Only leading commponent indexes are considered for use by the compiler.

For more information about how an index is selected, see General rules for choosing a single index and How ABL chooses and brackets indexes to satisfy queries in OpenEdge Web Paper: ABL Database Triggers and Indexes.

Use the COMPILE statement with the XREF option to identify the indexes used for the queries in your code. For more information, see COMPILE XREF option in Troubleshoot ABL Applications.

Reduce network traffic

Take advantage of server-side join processing to reduce the data pulled from the server. For more information, see Server-side join processing in OpenEdge Programming Interfaces.

Build an efficient temp-table

Temp-tables provide the same opportunity to optimize performance as database tables provide, only on a smaller scale. When you build a temp-table, do the following:

  • Add only those fields necessary for the current task.
  • Add only those related tables for the current task.
  • Add only those indexes that are required for the current task.
Datasets are based on the underlying temp-table definitions, so make every effort to build efficient temp-tables.

Identify and avoid potential ABL bottlenecks

Development is the best time to start reviewing your code for potential bottlenecks. Developers can use the ABL Profiler utility to review their code for potential bottlenecks. For example, you can look for which part of the application is taking the largest percentage of your application processing time. Originally created for technical support engineers, profiling can identify problems on development, test, staging, and production environments.

Here is an introductory video that provides a tour of the ABL Profiler utility:

Get Started with Developer Studio

For more information, see, Using Profiling to Develop Better ABL Code , Profiler View in Progress Developer Studio for OpenEdge Online Help, PROFILER system handle in ABL Reference, and Profiler (-profile) startup parameter in Startup Command and Parameter Reference.