Re: [Libreoffice] Assertions and Logging

On Tue, Nov 22, 2011 at 1:41 AM, Stephan Bergmann <sbergman@redhat.com> wrote:
> On 11/22/2011 06:35 AM, Norbert Thiebaud wrote:
> > The run tine flexibility is a great feature, but the proposed
> > implementation is scary perf-wise
>
> I kept the implementation simplistic on purpose.  First, remember that
> logging (at least for now) is only enabled in debug/dbgutil builds, and that
> the SAL_LOG environment variable will have a rather short value most of the
> time (the default is just "+WARN").  Beware premature optimization.

Well,
first I do like the ability to use these kind of infrastructures even
on release code...
you'd need more level, but having a INFO or VERBOSE mode that survive
in release code can be quite
useful. You could imagine having the ability to collect trace, on the
user machine, about what dll got dlopen, when and from where,
about access to the user profile, which Registry was access what was
the value, etc...

But that can't be even considered if the system does not have a cost
~0 when the traces are inactive.

second: even parsing "+WARN" is a couple of order of magnitude (at
least) more expensive than 'if (lvl >= integer_constant)'
especially since, in order to get the parsing done, you need to have
all the argument of the log function evaluated and the call made.
in C++ that can easily mean, depending on the argument passed, object
creation + copy, etc...


> Second, static data is a problem, as is initialize-once data in a
> multi-threaded world.

humm ?? initialize _before_ getting to the multithreaded part.
Initialization only require getenv and parsing a string... it surely
does not require a large infrastructure, so you do that
as the first thing of main(), before anything get spinned out.
Beside the state-array is a compile-time constant size (depending only
on the defines that assign module_id. all you need is a MAX_MODULE_ID
and that
array is pre-initialized with 0 content. which happen to mean no-log.

>  To properly initialize it you need synchronization
> mechanisms, which are either platform specific or need to use osl/mutex.h,
> which in turn is undesirable.  "Avoid the use of other sal code in this file
> as much as possible, so that this code can be called from other sal code
> without causing endless recursion."  I already felt uneasy enough adding
> OSL_DETAIL_GETPID.

if you test up front, for log message, in a macro, before getting in
the formatting and all, you do not have any recursion.
If you call too early (before the setup is done/finished) these log
message are just not triggered.

> Third, free-form string area codes are indeed not optimal.  But I fear typos
> here more than I fear performance problems.  And their advantage is that
> they need zero centralized configuration.

I'm not arguing against the format of the configuration, but against
the delayed-parsing repeated for each and every log message.
(which is pointless since you use an env-variable so it is an
execution-invariant -- unless you are thinking about adding a
uno-service to change it on the fly ;-) )


Norbert