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
