https://bugs.documentfoundation.org/show_bug.cgi?id=91872
Bug ID: 91872
Summary: make SAL_INFO and friends more efficient ...
Product: LibreOffice
Version: unspecified
Hardware: Other
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: sdk
Assignee: [email protected]
Reporter: [email protected]
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 !
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
