On Tue, Nov 22, 2011 at 1:41 AM, Stephan Bergmann <sberg...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice