Talking about speed and performance, I just came across an issue that was also discussed in db4o forums very recently: Sort operations on large datasets.
Note: This has nothing to do with linq or linq to db4o, it’s just the same for SODA queries.

Let’s take a very common example: Find some most recent items, for example most recent blog/forum posts or some other ‘top list’ on a very large amount of entries N:

        var mostRecentPosts = (from Posts o
              in ObjectContainer
              orderby o.Created descending
              select o).Take(100).ToList();

This query will be really really slow on a large amount of objects. Why? Essentially, the BTREE operation is very fast as it should be, but unfortunately db4o will invoke its SODA system on each of the objects, even if they are already outruled by the BTREE operation.

See this discussion on the db4o forum and the associated Jira-bug.

This is somewhat sad, because a query on a previously filtered set of items is blazing, about 100x faster:

        var mostRecentPosts = (from Posts o
              in ObjectContainer
              where o.Created > yesterday
              orderby o.Created descending
              select o).Take(100).ToList();

The latter operation plays roughly in the same league as SQL Server (don’t flame me – performance comparisons and profiling is really complicated and there is a zillion of factors that influence it, I know. That’s why I say ‘roughly the same league for this query’ and I’m talking about default setups).

This is a somewhat unfortunate situation, because it produces slow queries for many typical applications – unless you have a strong where clause that cuts down N from millions to hundreds. If you’re interested in seeing this issue fixed, head over to their issue tracker and vote for the issue to be fixed! Thanks!

I’ll be posting a bit more on db4o over the next few days I hope.

It’s actually in the manual so this is not exactly a secret, but I managed to overlook it so perhaps I’m not the only one…

In our specific scenario, db4o was about 3 times slower than MSSQL via Linq to SQL in the past days.

Just a few minutes ago, I finally read this:

Native Query optimizer for .NET requires the following libraries to work:
Db4obects.Db4o.Instrumentation.dll
Db4objects.Db4o.NativeQueries.dll
Mono.Cecil.dll
Cecil.FlowAnalysis.dll

(see http://developer.db4o.com/Documentation/Reference/db4o-7.12/net35/reference/html/reference/tuning/native_query_optimization.html)

I added these dll’s to my solution and wooosh! Now it’s up to 50 times faster than before! That’s what I needed… Will see how this works with larger data sets…

Update: There have been some important changes in builds past 14021, see my more recent post on that topic. In short, the new kid in town is Mono.Reflection.dll, which took Cecil’s place.