[soc] Boost.extension/reflection project advances
Hi Community! I'm writing this email to keep you informed about the progress of the library. I'll try to be short and go directly to mention the work that we have done this week: - We have new examples. One is about registering classes with arguments in their constructors and the other is about using the Info class to differentiate versions in different implementations of a class and to show/test some edge cases. - Also we have finished a new unit test checking edge cases in functor arguments limits. - We have done some benchmarking comparing extensions approach with the old plain style using dlopen/dlsym/dlclose. Then we've done some profiling. - We have a new tutorial about dealing with classes that receive arguments in their constructors. We are planning for this week more documentation, fix some problems with the build system, some optimizations according to the profiling, fix some bugs and start cleaning up the code to conform Boost style guide. Bye! -- Mariano
We have a number of other benchmarks to write. The basic test Mariano did (which is in the subversion repository) opens a shared library, instantiates a plugin, calls a very basic virtual function, deletes the plugin, and then closes the shared library. The minimal approach using direct dlopen,dlsym,dlclose was approximately three times as fast (faster is expected - Boost.Extension does those same calls underneath, and also has to store a bunch of type information). Using profiling, it appeared that most of the overhead was in string creation and destruction, because the current implementation uses strings for type info by default (since some platforms can't just compare type_info references across shared libraries). We're going to test it using integer IDs for type info, and see what the result is. It may actually work with const char * instead of string as well. We're also going to test it using type_info references on platforms that support it. We'll try and post those results next week. We also need to test opening many shared libraries - opening the same shared library repeatedly is not a great indicator of the actual load the library will be under in real world situations. It is likely that the first time the library loads takes much longer than the later loads - since the OS isn't actually required to close the library when you ask it to. Jeremy On 6/13/07, Michael Marcin <mmarcin@method-solutions.com> wrote:
Mariano Consoni wrote:
- We have done some benchmarking comparing extensions approach with the old plain style using dlopen/dlsym/dlclose.
Did it compare favorably?
Thanks,
Michael Marcin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
Jeremy Pack said: (by the date of Thu, 14 Jun 2007 09:40:57 -0700)
We have a number of other benchmarks to write. The basic test Mariano did (which is in the subversion repository) opens a shared library, instantiates a plugin, calls a very basic virtual function, deletes the plugin, and then closes the shared library.
try unloading the library, replacing the *.so (*.extesnion) file with another file - the very same class. Only difference is that the basic function returns a different value, or prints different message on the screen. Then loading that library again and calling the function, without restarting the test program. I tried it just once with my plugin library and it didn't work. The cached plugin file was used instead. But I didn't spend any time to fix that. Only checked how it behaves. It may be important that the plugin file has the same filename, but different contents. I belive that above test should be a part of your testing suite - if you plan to support unloading plugins and reloading them later on runtime. -- Janek Kozicki |
Jeremy Pack wrote:
We're going to test it using integer IDs for type info, and see what the result is. It may actually work with const char * instead of string as well.
It, const char * that is, won't work in at least msvc. What I've done in the past is do a hash of the type name for comparison. Of course if you really wanted to get fancy, you'd use a trie for the type map. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 6/14/07, Jeremy Pack <rostovpack@gmail.com> wrote:
[snip]
We also need to test opening many shared libraries - opening the same shared library repeatedly is not a great indicator of the actual load the library will be under in real world situations. It is likely that the first time the library loads takes much longer than the later loads - since the OS isn't actually required to close the library when you ask it to.
FWIW, I'm not concerned about opening and closing performance of boost.extension. I'm only concerned about function calls of plug-ins. Which should be fast enough.
Jeremy
-- Felipe Magno de Almeida
FWIW, I'm not concerned about opening and closing performance of boost.extension. I'm only concerned about function calls of plug-ins. Which should be fast enough.
Yep - it should just have standard virtual function call overhead, since we're making calls through base class pointers. We're going to be a bit more concerned with tracking the performance of the reflection part of the library. Jeremy
participants (6)
-
Felipe Magno de Almeida -
Janek Kozicki -
Jeremy Pack -
Mariano Consoni -
Michael Marcin -
Rene Rivera