Hi,
Recently we decided to evaluate how much impact (in performance) reflection represented in db4o.
In .Net side we already knew (due to previous experience) that reflection is not as fast as we would like to.
At the same time, profiling proved that reflection was not a bottleneck in Java side.
So we settled up for trying to replace the reflection layer (in .Net) used to set / get field values at store / retrieval time.
What we did was basically emit a setter / getter method dynamically (using DynamicMethod) for each field. These setters/getters are able to directly access object's fields (even private ones),completly avoiding reflection (to be more precise, reflection is used to some extent to generate the setter/getter methods). Once generated we keep these setter/getter methods cached to avoid regenerating them needlessly. In other words we are trading space (memory) for performance.
One aspect of current implementation is that the getter/setters cache grows indefinitely. If we do get reports about performance improvements, and so we decide to use this mechanism (either by default or through a configuration) we can introduce MRU (or MFU) and cache expiration strategies to keep memory usage as low as possible).
Even doing some benchmarks we don't have enough data to take conclusions. For instance, our benchmarks pointed to a 8 ~ 10% improvement but when we tried to run our full test suite with this new "reflection" layer we got worst results (more time to run) (but surely our test suite is not a good candidate as a benchmark for this setting; it has lots of different classes and do lots of disk accesses to emit assemblies for regression tests and the like).
The version in trunk still uses the traditional reflection layer by default. You can configure your application to use the fast reflection layer with:
IEmbeddedConfiguration config = Db4oEmbedded.NewConfiguration();
config.Common.ReflectWith(new FastNetReflector());
IObjectContainer db = Db4oEmbedded.OpenFile(config, "database.odb");
Alternatively you can recompile the Db4objects.Db4o assembly so it uses the new reflection by default. All you have to do is to define a USE_FAST_REFLECTION symbol and recompile db4o assembly.
So, if you think this "reflection less" getters/setters could improve performance for you and you are willing to help db4o community, please, use it (either by configuring the reflector or by recompiling db4o with USE_FAST_REFLECTION) and deploy your application to an environment as close to a live one as possible and gather some data regarding performance and let us known.
Best
Adriano / Rodrigo