Prepared Statment Cache

[amattn]

current benchmarks seeing approx 85% performance improvement with load, ~60% with save.

Most of what I learned about database/sql came from here:

https://github.com/VividCortex/go-database-sql-tutorial

A great read and one of the key takeaways was that you should pretty much always be using prepared statements.

This particular implementation of a statement cache includes lightweight wrappers around Exec, Query and QueryRows so that the cache can be a drop in replacement. Compare benchmark examples to see the two line code changes.

A more through implementation would possibly be integrated into Save/Load directly. Also a future enhancement could be the use of an LRU or adaptive replacement cache, rather than the naive, permanent cache in this pull request.

[amattn]

More bencharks:

The environment is a bit suspect (running on an ubuntu VM inside of Mac OS X rMBP) but the general trends seem to hold up across all three DBs:

db	iterations	ns/op
BenchmarkAccountLoadMySQLJustQuery	10000	159330 ns/op
BenchmarkAccountLoadMySQLStmtCache	50000	68516 ns/op
BenchmarkAccountSaveMySQLJustQuery	5000	523984 ns/op
BenchmarkAccountSaveMySQLStmtCache	5000	418545 ns/op
BenchmarkAccountLoadPostgresJustQuery	5000	511377 ns/op
BenchmarkAccountLoadPostgresStmtCache	5000	223409 ns/op
BenchmarkAccountSavePostgresJustQuery	2000	674551 ns/op
BenchmarkAccountSavePostgresStmtCache	5000	416172 ns/op
BenchmarkPersonLoadSqliteJustQuery	50000	48341 ns/op
BenchmarkPersonLoadSqliteStmtCache	100000	25834 ns/op
BenchmarkPersonSaveSqliteJustQuery	50000	45366 ns/op
BenchmarkPersonSaveSqliteStmtCache	100000	28182 ns/op

[russross]

I do want to include statement caching, but there are a few things I want to work out first. So I'm not ignoring you, but I'm not quite ready to merge anything yet.

[amattn]

@russross No worries! Looking forward to it.