Anuj Dhawan wrote: ↑Tue Jan 29, 2019 10:22 amWith STROBE, we'd request it to be applied on a production code which has been identified as a CPU hogger, it was for very small time, in prod and was expensive, as it was at run time...as Robert has said.
Yes, it is expensive, but given the potential savings using Strobe can give, it's worth using it on production data, as test data may not be sufficient in volume to find hotspots.
Using it at one client I reduced the CPU usage of two routines by 99.5 and 99.7%, and at my last employer I found out that the idiots who ran the shop were using the "STORAGE(0,0,0)" LE option, "because the third-party who helped us moving from OS PL/I to Enterprise PL/I [prino: some eight years earlier!] told us to do so", go figure...
And at another client I found that PL/I code using the "BASED REFER" option was eating CPU like there was no tomorrow. A slight restructure of the code eliminated that hotspot, and the method I used is still recommended in the current Enterprise PL/I manual, if you open the EPLI V5.1 Programming guide on (pdf) page 331, you can read
When your code refers to a member of a BASED structure with REFER, the
compiler often has to generate one or more calls to a library routine to map the
structure at run time. These calls can be expensive, and so when the compiler
makes these calls, it will issue a message so that you can locate these potential
hot-spots in your code.
If you do have code that uses BASED structures with REFER, which the compiler
flags with this message, you might get better performance by passing the structure
to a subroutine that declares a corresponding structure with * extents. This will
cause the structure to be mapped once at the CALL statement, but there will no
further remappings when it is accessed in the called subroutine.
And that's nearly a literal copy of what I sent to IBM in the late 1990'ies.