The format of the varints in the DB were not changed. For Varint32s, the macro support was cleaned up and changes made to use it consistently. The MACROs inline the single byte case, so code for this was disabled in the actual function. The actual functions were re-implemented to utilize loop unrolling and some bitwise anding and shifting to minimize the number of binary operations required.
Varint32s are used quite a bit for storing record structure information (header size, field size, etc.) Performance testing was done using the various speed*.test scripts, the speedtest8.c utility, and valgrind. The newer implementations showed the most improvement for large varints (>4 bytes). Typical "wall-clock" improvements were about 1%. When the scripts were changed to force greater usage of large varints, improvements of up to 4% were measured. No slowdowns were observed. It should also be noted that from this testing, corruption detection for certain bad varint32 values in headers was improved. On 5/15/08, Mark Spiegel <[EMAIL PROTECTED]> wrote: > > The release notes for 3.5.9 indicate that performance improvements have > been made around the way integers are stored. > > "Performance enhancement: Reengineer the internal routines used to > interpret and render variable-length integers." > > Can someone in dev add some color to this statement? What types of > operations does this affect? Any information on the magnitude of > improvement and how this is measured? > > Best Regards > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users