On 25.03.2010 19:15, Stewart, Robert wrote:
- The library should not reinvent wheels. In particular, custom implementations of TSS and RW mutex seems like a very bad idea.
I have noted that during the review that these tools were implemented for a reason. They make the library faster and lighter in terms of memory footprint. They allow to avoid including Boost.Thread headers in public headers of Boost.Log, which also speeds up the compilation. I think these matters are more important than having the code dispersion they add.
I'd like to know the real effect of using off-the-Boost-shelf components rather than your special sauce. That is, I'd like to know the performance and compilation tradeoffs for them before commenting further.
Here are the numbers regarding the memory footprint and the lightness: On Linux x86_64, GCC 4.4: ========================= $ g++ -I. -E ./boost/log/detail/thread_specific.hpp >bl_tss.pp $ g++ -I. -E ./boost/thread/tss.hpp >bt_tss.pp $ g++ -I. -E ./boost/log/detail/light_rw_mutex.hpp >bl_rw.pp $ g++ -I. -E ./boost/thread/shared_mutex.hpp >bt_rw.pp $ ls -la 82157 2010-03-25 19:26 bl_rw.pp 157431 2010-03-25 19:24 bl_tss.pp 1205108 2010-03-25 19:26 bt_rw.pp 347240 2010-03-25 19:24 bt_tss.pp sizeof(shared_mutex) = 192, sizeof(light_rw_mutex) = 56 On Windows, x64, MSVC 9: ======================== E:\Sources\_SVN\boost-release>cl -I. /TP /EHsc -E boost\log\detail\thread_specific.hpp >bl_tss.pp Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. thread_specific.hpp E:\Sources\_SVN\boost-release>cl -I. /TP /EHsc -E boost\thread\tss.hpp
bt_tss.pp Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved.
tss.hpp E:\Sources\_SVN\boost-release>cl -I. /TP /EHsc -DBOOST_LOG_USE_WINNT6_API -E boost\log\detail\light_rw_mutex.hpp >bl_rw.pp Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. light_rw_mutex.hpp E:\Sources\_SVN\boost-release>cl -I. /TP /EHsc -E boost\thread\shared_mutex.hpp >bt_rw.pp Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. shared_mutex.hpp E:\Sources\_SVN\boost-release>dir Volume in drive E is Dev Volume Serial Number is E050-708C Directory of E:\Sources\_SVN\boost-release 25.03.2010 19:52 394 755 bl_rw.pp 25.03.2010 19:55 776 216 bl_tss.pp 25.03.2010 19:51 4 360 402 bt_rw.pp 25.03.2010 19:49 3 823 468 bt_tss.pp E:\Sources\_SVN\boost-release>cl -I. /TP /EHsc -DBOOST_LOG_USE_WINNT6_API -DBOOST_ALL_NO_LIB size_test.cpp Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. size_test.cpp Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. /out:size_test.exe size_test.obj E:\Sources\_SVN\boost-release>size_test.exe sizeof(shared_mutex) = 48, sizeof(light_rw_mutex) = 8 I draw your attention to that a typical MT logger (at least, ones provided by the library) contains a rw mutex, which makes it a significant addition if loggers are used as class members. Regarding performance, Boost.Log TSS relies on raw pthread/WinAPI calls, while Boost.Thread TSS adds to that a logarithmic lookup along all thread_specific_ptrs in the application, so it definitely cannot be faster. Also, using thread_specific_ptr to manage a tiny thing like an integer (the severity level) is an overkill since it would require several memory allocations per thread, one of which is for shared_ptr, IIRC. That's opposed to no allocations at all for Boost.Log TSS.