I get asked quite a bit about why we are continuing to add new features, or as one user put it “What is with the feature frenzy?  Are you in a hurry?” 
And some of you put it in different terms on the user questionnaire, “Stop adding new features and optimize what you have”. I want to address both of these concerns in this blog post.

Features, what are they good for?

Why are we continuing to add new features?  Is it just to say we are more compatible with SQL Server?  No, that is not it.  The biggest reason we are adding all these features is because they were requested by users, and promised to them over six months ago.  Most of the features we are adding today were promised to some people over a year ago (not by me, but they were still promised). 

We are on target for our goals

We mapped out this year back in April as to what we would do and when.  We are on target right now with where we wanted to be, feature wise. The server is probably going to be late, but the core engine is now where we want it to be as a feature set for 3.x.  The only other major additions are the Sync Services, and LINQ.  Neither of which will effect core engine design at all.

What about the features for next year?

The main plan for next year is not to continue to add new features.  It is for optimization.  I think we are pretty set for features right now, we have some minor SDK changes to make, and some syntax to tighten up to be more compliant.  Nothing major is going to change after the release of 3.3 with respect to the SDK.  Unless (there goes that word) we see something as a course of optimization.

Optimization, why now?

I also get asked repeatedly why are we waiting to optimize some aspects of the engine that have been in place “forever”.  There really is a method to my madness.  I have been programming a very long time (actually started with a VIC-20 when I was very young).  In my tenure with programming on large projects I have learned that you spend a huge amount of time optimizing a very small percentage of your code.  The key is always WHAT code to spend that time optimizing.

How can you optimize without a complete engine?

This is my question to programmers all the time – How can you optimize without a completed base of code?  The answer of course is that you can’t do it and know you are doing it right.  You can take guesses, but they may turn out to be wrong.  I prefer to wait until the core engine of any design is feature complete before I turn my eye towards optimization.  If we had optimized a part of the engine that then needed to be rewritten for stored procs we would have wasted all that time. This engine is one of the most modular designs I have ever worked with, but even it has some layering concerns for optimization.  You may optimize a single layer only to find out you actually hurt a layer that depends on it.  Those are the special purpose cases where you end up duplicating code logic for the sake of optimization (unrolling loops, special purpose and special case logic).  Duplicating that code or logic prior to completion of the engine would have been a nightmare.  You end up with non maintainable code. I prefer to get a base implementation complete and working first – reach feature complete.  Then you can build special purpose functions and logic and place them in areas that are easily turned off.  You can ifdef them, or you can have the engine know about optimizer on and off type logic.  Either way you always leave your base implementation in place, and put newer logic around it.

Now can we optimize?

Yes (as soon as 3.3 is released).  I feel that we are now finally in a position to go back and revisit each layer of the engine looking for special purposes, optimizations, and assumptions in the design that never came true.  These exist in every project at some level.  The key for us going forward is to have a good base of code to fallback and regression test against at all times.  Optimization is much more an art than a science.  Many times it comes down to a gut feeling that you have to test.  The science of measuring routines and objects for timing only goes so far.  Most of the big gains you will get in optimization is from seeing a new algorithm to apply to the situation.

We can only get better

I honestly believe from here on out we can only get better.  And yes, I feel we have a ways to go to reach the performance goals I expect from the engine.  I know we can do it, but all things take time.  The best thing about having an engine gain performance for you is that your app does not have to change at all, you plug in a new engine and get “free” performance.

Thanks, as always, for all your emails and support of VistaDB.  We wouldn’t be here without you guys.