The number of trace statements to embed in your RDML code is entirely up to you.
Inclusion of too many trace statements may be counterproductive and will produce enormous trace files which are difficult to analyse. At the other extreme, only including sporadically placed trace commands into your RDML code with no real structure may be of little use in identifying issues.
It is recommended to do some analysis of your application to identify critical code and areas of interest, for example, after a record has been read or before a record is updated, or perhaps when invoking a subroutine or method to manipulate data, it may be beneficial to add tracing commands before and/or after the code is executed.
Also consider standardizing the format of your trace output to include the type of the processing to be performed as well as the data values at the time. This can greatly improve the understanding of the output without necessitating great familiarity with the RDML source itself.
#Sys_Appln.TraceMessageText("UPDATE Employee &1 Name &2 &3" #Empno #Givename #Surname)
The trace feature is designed specifically so the trace commands can be embedded in your application and left there without adverse performance impact. If the trigger mechanism to start tracing is not activated, the trace handler will not be installed. Consequently when a call to the trace method is made there is nothing to do. This is equivalent to calling an empty method and has a negligible performance overhead. Simple tests demonstrate that 100,000 trace statements add about a quarter of a second to the run time when tracing is inactive If tracing is activated, the trace processing added about 45 seconds to the total execution time.