Guardrail #4: Avoiding Java steps in activities
This presentation is part of the Designing and Building for Performance Self-Study Course.
Java code warrants a warning because the code itself may be poor performing, difficult to maintain, or simply used for debugging, as it is in this case. This warning pertains to guardrail #4 "Limit Hand-Coded Java".
Often times, programmers who are very familiar with Java tend to resort to Java steps instead of using the preferred, and easier to maintain, PRPC equivalent of out-of-the-box methods that do the same thing.
Verbose logging may seem innocuous, but it can have a noticeable impact on performance for a few reasons:
- Using println() in this case synchronously attempts to write to sysout, which can create a bottleneck.
- Using the PRPC Log-Message method is a better approach that uses the Log4J facility instead, which is asynchronous and more efficient.
- Also, note how the string being written is made up of a concatenated set of sub-strings and tokens. This process can also throw off garbage in the JVM as the string concatenation can be inefficient from a memory management perspective. The token generated from the call to getXML() can be quite large depending on the size of that object and can also be memory intensive.
- Instead of reverting to Java, a better practice is to use the PRPC OOTB method Log-Message, which accomplishes the same goal without resorting to more complex Java coding syntax.
- As a debugging aid, unconditional logging can be useful, but is not production-worthy code.