How to write an efficient PeopleCode?

Reduce Server Trips

Accessing the sever in between the field navigations causes sever performance issues and it is imperative to manage these trips to make a better coded application.

What happens in a server trip? 

• All the below activities are repeated for each server trip.
• Checking security
• Unpacking the buffers that store the data being processed
• Processing the service request
• Generating the HTML for the page to be redisplayed
• Packing updated buffers
• Storing the buffers on the web server

The below items brings in server trips

• Entering data in fields with FieldEdit or FieldChange PeopleCode.
• Entering data in fields that have prompt table edits.
• Entering data in fields that have related displays.
• Inserting a row in a grid or scroll area.
• Deleting a row from a grid or scroll area.
• Using grid or scroll area controls to move forward or back.
• Accessing another page in the component.
• Selecting an internal tab.
• Expanding or collapsing a collapsible section.
• Clicking a button or link.

Steps to identify and control server trips

• Analyzing server trips: showcounters = 1
• Using Deferred mode whenever possible
• Avoid using FieldChange PeopleCode to hide, unhide, enable, or disable elements on the same page. Hiding or unhiding objects and enabling or disabling objects should, as a general rule, be coded in either page Activate PeopleCode or, for objects that are on another page in the component, in FieldChange PeopleCode.
• Clicking the Refresh button forces a trip to the server
• Make the calculations / totaling in the deferred mode
• Use warning messages in Deferred mode with proper value tagging 
• Use %PerfTime which helps you to determine how long a program takes to execute and adjust it accordingly

Other recommended methods includes

• Run a SQLTrace and review the transaction for SQL statements that have a long processing time and tune it with the assitance from the DBA
• A simple join optimizes SQL more effectively than issuing two related SQL statements separately. 
• While working with the counter, use the GetNextNumberWithGaps PeopleCode function to avoid unwanted commits.
• Minimize the events to be triggered and consolidate the PeopleCode under less number of events for better managing and performance.
• Messages sent online should always be coded in the SavePostChange event. Safer that the message will not send until the commit happens
• Use metadata and Rowset Cache
• Increasing MaxCacheMemory. Keeping a low memory space can degrade the performance when a significant cache is created and lower the performance
• Declare all variables upfront and specifically by the type and do not leave the program to do the auto declaration
• Create application packages for repeated and re-usable code fragments

If you have your suggestions, please comment it below and I  will incorporate in this post.