Here is some sample code RowInit PeopleCode:
Declare Function BuildHTMLString PeopleCode MY_FUNCLIB.MY_FIELD FieldFormula;
BuildHTMLString(GetField(WORK_RECORD.MY_TEXTFIELD), …. some other parameters);
The underlying Function is defined as you might expect:
On the surface there is not a lot wrong with this code but it contains a technique that can hurt performance – passing around and using object references when you really don’t need to. This technique comes from the OO programming world and is absolutely valid but all this function is doing is building a string value. Changing the code so the Function RETURNS a string and using simple assignment in the RowInit logic is another option:
But is this really faster? And by how much? In my benchmarking of 10000 rows, the first version took some 14 seconds elapsed time to populate. The string assignment version took under 2 seconds. Now this was on a laptop of limited resources, but I think this illustrates a valid point – think about the cost of passing objects around and consider the impact on performance in medium to high volume situations. Anything that releases the app server to do other work quicker is good in my view.
Of course building the string in the underlying SQL is an even better option from a performance perspective – but only if all of the logic in the function can be coded in SQL. Sometimes that just isn’t feasible and PeopleCode is the best way to go.