Almost all profiles I see of dbgutil builds have lots of time spent in constructing and then discarding SAL_INFO type output via nested stream operators, a with lots of allocation & freeing going on too. That is true even when (as in the normal case) none of that information is actually output.

It would be great to fix this by exposing the function:

sal/osl/all/log.cxx:
    bool report(sal_detail_LogLevel level, char const * area)

and giving it a sensible extern "C" name and wrapper eg. sal_detail_log_report - I suspect that will need a punch-through in the sal/ map file too checkout:

sal/util/sal.map

Then we should tweak the macros in the log headers:

#define SAL_DETAIL_LOG_STREAM(condition, level, area, where, stream) \
    do { \
        if (condition) { \

(and friends) to do:

        if ((condition) && sal_detail_log_report((level),(area))) { \ ...

instead - and (hopefully) hey-presto we save doing a ton of function calling just to discard the result.

For bonus points we should create a wrapper of __builtin_expect - eg. SAL_UNLIKELY or SAL_LIKELY etc. to ensure that this code is annotated as ~never happening and thus piled up in some section elsewhere so it has a far smaller icache impact too =)
 
Thanks !