Frankly, I wouldn't care.
http://asktom.oracle.com/Misc/instrumentation.html Code in production must be fully instrumented. It must be ready - at the drop of a hat - to start pumping out the diagnostic information (look at the Oracle database, we left all of our "printf's" in the database - not only "even in production" but "especially in production"). If the production code is not instrumented for debugging, maintaining, figuring out "what went wrong" and so on - it is pretty useless.
ops$tkyte%ORA10GR2> create table t1 ( x int );
Table created.
ops$tkyte%ORA10GR2> create table t2 ( x int );
Table created.
ops$tkyte%ORA10GR2>
ops$tkyte%ORA10GR2> set serveroutput off
ops$tkyte%ORA10GR2> exec runStats_pkg.rs_start;
PL/SQL procedure successfully completed.
ops$tkyte%ORA10GR2> begin
2 for i in 1 .. 100000
3 loop
4 insert into t1 values ( i );
5 dbms_output.put_line( 'we inserted ' || i );
6 end loop;
7 end;
8 /
PL/SQL procedure successfully completed.
ops$tkyte%ORA10GR2> exec runStats_pkg.rs_middle;
PL/SQL procedure successfully completed.
ops$tkyte%ORA10GR2> begin
2 for i in 1 .. 100000
3 loop
4 insert into t2 values ( i );
5 end loop;
6 end;
7 /
PL/SQL procedure successfully completed.
ops$tkyte%ORA10GR2> set serveroutput on
ops$tkyte%ORA10GR2> exec runStats_pkg.rs_stop(10000);
Run1 ran in 467 cpu hsecs
Run2 ran in 409 cpu hsecs
run 1 ran in 114.18% of the time
PL/SQL procedure successfully completed.
Now, your mileage will vary, more of the 14% extra was spent doing the actual string concatenation - it'll depend on the complexity of your "string" sent to dbms_output.
The put line routine starts with:
if (boolean_flag is false) then return; end if;
basically - it just returns.