On 11/23/2011 05:36 PM, Norbert Thiebaud wrote:
Seriously ? you need 'numbers' to be convinced that
b == 10
is more performant than (excerpt, not taking into account a couple of
epilogue/prologue among other things...)
[...]
Yes, I need numbers to be convinced that the difference is of practical
relevance.
at the very least: restrict the 'area' variable (the one that limit
base on module/feature) in the use-call to be something that could be
part of a variable/constant name
and use the #foo preprocesor to keep it string for now.
#define log(level, area, xxx...) _log(level, #area, xxx...)
that way at least we will be able to use a numeric value on day,
without having to change every use point
something like
#define log(level, area, xxx...) _log(level, SAL_AREA_ID ## area, xxx....)
While a central registry of such defines could be useful also for
consistency and to avoid typos, it is the very "central registry" aspect
that makes it look unattractive to me.
Also, how bad will the current scheme necessarily be in practice?
Whether to enable any output at all from any SAL_INFO or SAL_WARN,
resp., can be decided cheaply. Only if you enable output from, say,
SAL_INFO and want to further restrict it on area, *each* call to
SAL_INFO will incur an overhead. But what are the use cases? For
developers' debug builds, all of this will be rather irrelevant. For
production builds, my assumption is they would routinely log either
nothing at all or *all* SAL_WARNs. So only if a user would explicitly
enable certain area-restricted SAL_INFOs (to find out more about a
reproducible problem he experiences) would the decision to represent
areas as strings necessarily have negative consequences (which IMO would
again be tolerable in that special scenario).
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
