Cursor create is currently slower than it needs to be, and the problem is parsing the possible configuration options.

Creating a file, and then opening and closing a million cursors on pixiebob takes 19.75 seconds.

If you #ifdef out the calls to *wt_config_gets for "bulk" (*wt_curfile_create), "append", "checkpoint", "dump" and "raw" (__wt_cursor_init), it takes 5.25 seconds.

We could:

1. Change our position on caching cursors. The documentation currently says:

> Cursors are light-weight objects but may hold references to heavier-weight objects. Applications should usually not cache cursors as a performance optimization, instead, a new cursor should be opened for new groups of operations.

My concern is this wording tells benchmark writers to instantiate a new cursor for every get/update call, which isn't going to be as fast as it should be.

2. Avoid calls to __wt_config_gets when we're looking for non-default values, and no additional configuration has been specified, that is, if the open-cursor call has no configuration string (likely to be the common case), there's no reason to check for "bulk" or "raw", or any of the other strings, because the default is they aren't set.

We could do something like __wt_config_gets_not_default() as an inline function which checks if cfg[1] is NULL and returns "not set" in that case? That requires our current handling of cfg[0] and cfg[1], which is pretty ugly.

Michael, is this worth fixing, and/or do you have a better idea?