Coming soon

Wow, we just wrapped up Build 63.  You should see it on the site sometime this weekend.  All I can say is that the new Mike has done a great job of pushing VistaDB along.  New bug fixes, NUnit tests, lots of good things happened the past two weeks.

Nunit Suite runtime

The above numbers are the total time required to run the current NUnit test based on the engine from that date.  These dates do not correspond to any specific build of the engine, just what was in the revision control system on that date. 

The 27 April 2008 Engine took 271 seconds to run the current complete Nunit tests.

The 18 July 2008 Engine took 107.7 seconds to run the same set of tests. 

Double performance

That is more than doubling of performance on these tests. 

Not bad considering all we have done is minor tuning and tweaking of objects for strongly referencing.  We are not 100% complete with strongly typing all the internals of the engine, but the ones that are left are mostly there because they have to be. 

There are some aspects of ADO.NET that we can't change or it will break the public interface with the Provider Factories.  After seeing the performance differences I am really scratching my head wondering why Microsoft didn't provide strongly typed overloads for ADO.NET.  Why can't you request the schema in anything other than an ArrayList?  I don't see any changes in the 3.x line either as extension methods to help us here either.

VistaDB NUnit Memory footprint

The above numbers are the total time required to run the current NUnit test based on the engine from that

This chart is likewise a graph of the same engine runs Peak Memory footprint and the amount of memory in use at the end of the complete run.  These are not very scientific due to the nature of the Garbage Collector in dot net.  If you run the same tests on this exact same machine with only 1 GB of memory you will see totally different results.  The only way you can compare is to run the same tests on the same machine.  All of these tests were run on the same machine with 4GB of RAM on Windows Vista x64.

The peak memory footprint came down from 190MB to around 140MB.  That is respectable, but also shows just how much overhead you incur just by casting objects around.  All those temp objects add up, and the GC will get around to them when it is good and ready.  You could easily see higher numbers than this just due to when the GC decided to clean up (we don't force GC's in the NUnit suite).

Strongly type it all

Ah, I wish we could.  Some things will have to stay weakly typed for ADO.NET.  I am hoping that as the Entity Framework provider starts to take better shape we will have a better idea of how to stay strongly typed while providing services to the Entity Framework provider. 

Microsoft did make some changes so we can pass around our internal command objects rather than requiring us to convert everything to strings.  This should help us quite a bit in managed land since we will not have to parse and tokenize strings all day before the engine can actually do something.

We will continue to make changes in the engine to improve performance, drop the memory footprint, and hopefully improve throughput as well.