@michaelcahill, here's another branch that's been hanging around in my tree for awhile, cleaned up for your consideration.

In summary, I'm building an array of offsets into the static configuration arrays so that __wt_config_get can do a binary search instead of a linear walk.

This change is pretty ugly in one specific way: I'm prepending a magic key/value pair at the front of every base configuration string, but I couldn't think of anything better.

IMNSHO, it would be great if the default configuration strings were an array of strings, one per configuration key, so a binary search would fall out of the design the same way it does for the API check function.

I took a run at doing that: I created a WT_CFG structure to pass around instead of const char *cfg[]:

struct __wt_cfg {
    WT_CONFIG_ENTRY *base;      /* Base configuration */
    const char *cfg[];          /* Other configuration */
};

That works well and I think it would be great if we'd done that from the start, but what scared me about that change was the sheer scope. We have const char **cfg wired into everything, everywhere, and lots of code just <b>knows</b> that cfg[0] is the base, cfg[1] is the application-specified config string, and so on and so forth. While I like that change, it'd take us a month to clean up.

The bad news is that as far as I can tell, linear searches of the configuration strings cost us somewhere between 10-15% <b>when it costs us anything at all</b>. This branch is about 13% faster when opening a statistics cursor, and doesn't gain us much of anything when opening a table cursor because we've reworked the cursor requests in the table open path to call __wt_config_gets_def, which gets no gain from this code because it doesn't search the base configuration.

@sueloverso, I remember you had a test where cursor open was expensive. If you still have that around, I'd be interested in knowing about it, I'd like to run it against this branch and see if it makes any difference, maybe I'm missing something, and this branch is more useful than I think.

Anyway, Michael, I'm prepared to discard this branch as not worth the effort, but wanted give you a chance to consider it.