On Wed, Nov 23, 2011 at 9:24 AM, Stephan Bergmann <sberg...@redhat.com> wrote:
>>> Second, static data is a problem, as is initialize-once data in a
>>> multi-threaded world.
>>
>> humm ?? initialize _before_ getting to the multithreaded part.
>
> which a *library* like sal cannot do

who said that sal has to auto-initialized the service.

main() explicitly call sal_init_trace_services(char*
log_env_descrition) (or whatever) and store the resulting array of
logging context in a globally visible variable that the tracing macro
can use.

>
>> 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 ;-) )
>
> Honestly, I am not worried about the performance of the current
> implementation at all.  If it should ever become a bottleneck (esp. if we
> ever decide to enable logs in production builds), we could rather easily
> improve it (though by adding complexity), without (that's my hope having
> designed it that way) having to modify the interface.

If you use a string as a trace-selector you will never get something
with performance good-enough for release code.
you need a numeric level and a numeric module/feature selector.

You need a system so that when the trace are not wanted a trace-point
cost a couple of integer testing at worse. you can't take a call, you
cant' have to construct arguments for the call,
you certainly can't have c++ object instantiation/clone/copy etc...

Norbert
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to