> It seems to me that, all of a sudden, a LOT of micro-wins and bigger wins
> are raining on the Sqlite/timeline
> (since about august 1rst, the "in ()" improvement)
> Is it an effect of a new Compiling/Testing environnement ? of summer
> vaccation ? of partner's help ?
> (maybe I'm wrong and all is as speedy as usual)
I think it is just perception. We are constantly working to improve
SQLite. That's what we do. Maybe sometimes that work is out-of-sight
because it is happening on non-public repositories (such as TH3 at
http://www.sqlite.org/th3/doc/trunk/www/index.wiki) but it is on-going.
By chance, I was just writing an annual report for an SQLite Consortium
member, and so I have some information at hand that I can share with you.
SQLite version 3.8.0 was release one year ago today. Since that time, we
have added the following major enhancements:
* WITHOUT ROWID tables
* Partial indexes
* Common Table Expressions
* The "skip-scan" optimization
* Partial sorting by index
* And many other smaller improvements.
The trunk today is 28.3% faster than the 3.8.0 release, which was in turn
the fastest version of SQLite up until that point. The 28.3% performance
increase is noteworthy because it was mostly obtained by small changes that
increase performance by 0.1% or 0.05% at a time. Such small changes are
scarcely measurable (we use valgrind to get precise CPU cycle counts) but
if you do enough of them, they add up.
The size of the SQLite library has grown over time. The current trunk is
4.9% larger than it was one year ago. Expect it to get larger still in the
days, months, and years ahead, though we are zealous to restrain the size
growth as much as possible.
The continuous improvement of SQLite is made possible by the SQLite
Consortium members, many of whom are listed on the SQLite homepage (
http://www.sqlite.org/). If you are using SQLite and appreciate its
reliability, performance, and features, then thank those Consortium members.