On 11/23/2011 06:55 PM, Norbert Thiebaud wrote:
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).
This is a self fulling prophecy. beside in order to exclude them all
you still need to parse your env variable no?
so sure the parsing will be (relatively) fast... but you still get a
couple of prologue, epilogue, a couple of variable initialization, a
get_env
so a no-op operation is still 100x more instructions than necessary.
actually reading the code if env = NULL you force it to +WARN and then
go ahead an parse it...:-(
As I already wrote, nothing keeps us from changing the *implementation*
if need be. I see no obstacle that would prevent fast paths for the use
cases of enabling nothing or enabling all SAL_WARNs.
To that extend, pushing as much or the complexity to the init function
and make the wrapper that trigger the trace as lightweight as possible
is desirable.
yes
Note that I'm arguing from a position where I'd like to have such
facility cheap and usable in release build.. this is above and beyond
what we currently have.
I'm on the same page here. It's just that I assume a string area can
still give us good overall performance, so would prefer to stick to that
design. Whether my assumption is true only time will tell, of course...
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
