Writing More Efficient Code

Follow these steps to write more efficient PeopleCode:

1. Declare all variables.

   One of the conveniences of PeopleCode is that you do not have to declare your variables before you use them. The variable is assigned a type of ANY, taking on the type of the value it is assigned. However, if you use this feature, you lose type-checking at compile time, which can lead to problems at runtime.

   When you validate or save PeopleCode, watch for auto-declared messages and consider adding declarations to your program.

2. Declare variable types specifically.

   Most of the time, you know a variable's type, so you should declare the variable of that type when you begin.

   For example, if you know that a particular variable is going to be an Integer value, declare it to be Integer in the first place. You can get much better runtime performance. It is particularly effective for loop control variables but, since an integer has limited range (up to 9 or 10 digits), you must use it judiciously.

3. Watch references.

   In PeopleCode function calls, parameters are passed by reference; a reference to the value is passed instead of the value itself. If you are passing a reference to a complex data structure, such as a rowset object or an array, passing by reference saves significant processing.

   Watch out for unexpected results, though. In the following code, the function Test changes the value of &Str after the function call.

   Function Test(&Par as String)
   
   &Par = "Surprise";
   end-function;
   
   Local String &Str = "Hello";
   Test(&Str);
   /* now &Str has the value "surprise" */
   

4. Put Break statements in your Evaluate statements.

   In an Evaluate statement, the When clauses continue to be evaluated until an End-evaluate or a Break statement is encountered.

   If you have an Evaluate statement with a number of When clauses, and you only expect one of them to match, put a Break statement following the likely clause. Otherwise, all the subsequent When clauses are evaluated. Your program is still correct, but it is inefficient at runtime, particularly if you have a large number of When clauses, and the Evaluate statement is in a loop.

5. Govern your state.

   One of the key features in PeopleSoft Pure Internet Architecture is that the application server is stateless. When required, the state of your session is bundled up and exchanged between the application server and the web server.

   For example, on a user interaction, the whole state, including your PeopleCode state, has to be serialized to the web server. Then, once the interaction has completed, that state is deserialized in the application server so that your application can continue.

   To improve efficiency:

   • Watch the size of PeopleCode objects that you create (strings, arrays, and so on) to make sure they are only as big as you need them to be.

   • For user interactions, you might be able to change the logic of your program to minimize the state.

     For example if you are building up a large string (a couple of megabytes) and then performing a user interaction, you might be able to change your program logic to build the string after the interaction.

   • For secondary pages that are infrequently accessed but retrieve lots of data, consider setting No Auto Select in the Application Designer for the grids and scroll areas on the secondary page, to prevent loading the data the secondary page when the page buffers are initially built.

     Then add the necessary Select method to the Activate event for the secondary page to load the data into the grid or scroll area.

6. Isolate common expressions.

   The PeopleCode compiler is not an optimizing compiler, unlike some current compilers for languages such as C++. For example, the PeopleCode compiler does not do common subexpression analysis. So, sometimes, if you have a complicated bit of PeopleCode that is used often, you can isolate the common expression yourself. This isolation can make your code look cleaner and make your code faster, especially if it is in a loop.

   In this example, notice how the common subexpression is broken out:

   /*---- For this customer, setup time on B is influenced by
        *---- the machine flavors of A. */
       &r_machine = &rs(&idB.GetRecord(Record.MACHINE_INFO); 
       If (&typeA = "F") And (&typeB == "U") Then
           &r_machine.SETUP_TIME.Value = 50;
       Else
           &r_machine.SETUP_TIME.Value = 10;
       End-If;
   

   The compiler has to evaluate each occurrence of the expression, even though it would only execute it once.

   Here is another example. Notice that once &RS and &StartDate are created, they can be used repeatedly in the loop, saving significant processing time.

      &RS = GetRowset();
      &StartDate = GetField(PSU_CRS_SESSN.START_DATE).Value;
      For &I = 1 To &RS.ActiveRowCount
         &RecStuEnroll = &RS.GetRow(&I).PSU_STU_ENROLL;
         &Course = &RecStuEnroll.COURSE;
         &Status = &RecStuEnroll.ENROLL_STATUS;
         &PreReqStart = &RS.GetRow(&I).PSU_CRS_SESSN.START_DATE.Value;
         If &Course.Value = "1002" And
               (&Status.Value = "ENR" Or
                  &Status.Value = "CMP") Then
            If &PreReqStart < &StartDate Then
               &Completed = True;
               Break;
            End-If;
         End-If;
      End-For;
   

7. Avoid implicit conversions.

   The most common implicit conversion is from a character string to a number and vice versa. You might not be able to do anything about this, but—by being aware of it—you might be able to spot opportunities to improve performance.

   In the following example, two character strings are converted into numeric values before the difference is taken. If this code were in a loop and one of the values did not change, performance would improve significantly by doing the conversion once, as the second statement illustrates.

      &Diff = &R1.QE_EMPLID.Value - &R2.QE_EMPID.Value;
   &Original = &R1.QE_EMPLID.Value;
   . . .
   &Diff = &Original - &R2.QE_EMPID.Value;
   

8. Choose the right SQL style.

   In certain cases, use SQLExec, as it only returns a single row. In other cases, you could benefit greatly by using a SQL object instead, especially if you can plan to execute a statement more than once with different bind parameters. The performance gain comes from compiling the statement once and executing it many times.

   For instance, code that uses SQLExec might look like this:

   While (some condition)
       . . .set up &Rec
       SQLExec("%Insert(:1)", &rec); 
   /* this does a separate tools parse of the sql and db compile 
   of the statement and execute each time */
   End-while;
   

   The following code rewrites the previous example to use the new SQL object:

   Local SQL &SQL = CreateSQL("%Insert(:1)"); 
   While (some condition)
   . . .Setup &Rec
   &Sql.Execute(&Rec); /* saves the tools parse and db compile 
   on the SQL statement and the db setup for the statement */
   end-while;
   

   SQL objects also have the ReuseCursor property, which can be used for further performance gains.

   See ReuseCursor.

9. Tighten up loops.

   Examine loops to see if code can be placed outside the loop.

   For example, if you are working with file objects and your file layout does not change, there is no reason to set the file layout every time you go through the loop reading lines from the file. Set the file layout once, outside the loop.

10. Set objects to NULL when they will no longer be accessed.

    Once you are finished with an object reference, especially one with a global or component scope, assign it to NULL to get rid of the object. This setting allows the runtime environment to clean up unused objects, reducing the size of your PeopleCode state.

11. Improve your application classes

    Simple properties (without get/set) are much more efficient than method calls. Be clear in your design about what needs to be simple properties, properties with get/set, and methods. Never make something a method that really should be a property.

    Analyze your use of properties implemented with get/set. While PeopleCode properties are in a sense first class properties with more flexibility in that you can run PeopleCode to actually get and set their values, make sure you actually need get and set methods. If all you have is a normal property which is more of an instance variable then avoid get/set methods. In the following example (without the strikethrough!) by having get/set for the property SomeString you have made it much more inefficient to get/set that property since every property reference has to run some PeopleCode. Often, this inefficiency can creep in when properties are designed to be flexible at the beginning and never subsequently analyzed for whether getters/setters were really needed after all.

    class Test
    ...
    property String SomeString get set;
    
    end-class;get SomeString
    return &SomeString;
    end-get;
    
    set SomeString
    &SomeString = &NewValue;
    end-set;