Daniel,
Would you please share your benchmarks?
I don't se how did you arrive at 30% overhead for the logging.
My benchmarks show no overhead attributed to java.util.logging.
I did try org.postgresql.benchmark.statement.ProcessResultSet.bindExecuteFetch, JDK 1.8.0_102,
columnIndexType = INDEX, getter = BEST, ncols = 5, nrows = 100, reuseStatement = false, type = BOOL, unique = false.
The results are:
9.4.1212:
150±8 us / op, 42032 bytes allocated / op
where op is "bind, execute, and fetch resultset of 100 rows, 5 bool columns each"
42.0.0:
120±8 us / op, 18032 bytes allocated / op
String results are exactly the same:
9.4.1212:
140±6 us / op, 54103 bytes allocated / op
42.0.0:
140±3 us / op, 54103 bytes allocated / op
That basically means, logging is a no-op provided it is not activated.
JFR recordings show no evidence of java.util.logging on the hot methods list.
logging.isLoggable is rather simple method (it does not walk logger hierarchy), so current logging is expected to be lightweight.
