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.
Second, static data is a problem, as is initialize-once data in a multi-threaded world. 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.
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.
Stephan _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
