Recently one top db4o's contributor just introduced some welcome changes to db4o LINQ implementation that improves both memory footprint and the time it takes to convert a LINQ query to something db4o can actually handle(i.e., a Soda query). Just as an example, db4o LINQ tests suite runs approximately 8% faster with this new approach.

The main change is the replacement (in the LINQ implementation) of Mono.Cecil/Cecil.FlowAnalysis by Mono.Reflection assembly (starting with revision 14204), so developers should deploy Mono.Reflection alongside normal db4o assemblies.

Note that these assemblies are still required for "Native Queries". Also, due to platform limitations, this improvement cannot be applied to Compact Framework, so, in this platform, db4o LINQ implementation still requires Mono.Cecil and Cecil.FlowAnalysis assemblies.

Done...but if you want to get more technical details about this change continue reading....

Warning: Highly technical content ahead

Just as a refresher, remember that the following query:

class User
{
   private string _name;

   public string Name
   {
      get { return _name; }
   }
}

var result = from User u in container
             where u.Name == "john"
             select u;
     
will be converted to something like (emphasis on the like part :

var query = container.Query();
query.Constrain(typeof(User));
query.Descend("_name").Constrain("john");

var result = query.Execute();

 

In current Production / Stable releases, db4o LINQ implementation relies on Mono.Cecil and Cecil.FlowAnalysis in order to map from properties or methods to the actual field that should be used in the Soda query (in this case _name). The "problem" using these libraries is that they are way more flexible than what db4o actually needs it to be. In other words, we are paying for this extra flexibility without getting anything from it (the old cost/benefit trade of).

The changes just introduced removes the dependency to these libraries, introducing a new, lightweight one (Mono.Reflection) that provides the means to figure out the same information (field name) avoiding doing a full fledged IL analysis (and possible, assembly loading / type resolution). The improvements, one will observe, are proportional to query complexity, so for simple queries (like the one above) the gains would be marginal; but on the other hand, queries touching multiple fields (as in: where/select clauses) will observe higher improvement gains.

Last, but not least, it's important to note that this new approach is not supported in Compact Framework (it requires direct access to method body IL which is not supported on this platform)

Best,

Yours db4o team.