[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Omaha.pm] Notes dump: pack, unpack, vec, and 2562 long bit vectors



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


<quote who="Jay Hannah">
> Benchmark: timing 1 iterations of byte, byte_onevec, char2562, char732...
>       byte: 30 wallclock secs (11.82 usr +  7.92 sys = 19.74 CPU) @
> 0.05/s (n=1)
>
> byte_onevec: 26 wallclock secs ( 8.35 usr +  7.02 sys = 15.37 CPU) @
> 0.07/s (n=1)
>
>   char2562: 34 wallclock secs (17.28 usr +  8.23 sys = 25.51 CPU) @
> 0.04/s (n=1)
>
>    char732: 13 wallclock secs ( 8.21 usr +  2.03 sys = 10.24 CPU) @
> 0.10/s (n=1)

Jay,

I noticed your timings included actual DB inserts.  If you re-ran this
with everything up to the actual "execute" command, did that make much of
a difference in speed?

If the test then equalized, it could be that the network and/or DB was
experiencing a bit of lag or other load during the specific tests.  I'm
just shooting in the dark -- you seem to have this testing thing pretty
well under control... :)

As a side note, I played with pack/unpack for the first time to experient
a bit.  I was wondering if you had tried playing with packing the 1's and
0's into a base-128 ("w") encoding?  I was trying to see if there was a
direct "string of 1's/0's to binary vector" function...probably the "vec"
function.

Dan

- - - - -
"I do not fear computer,
I fear the lack of them."
 -- Isaac Asimov
GPG fingerprint:9EE8 ABAE 10D3 0B55 C536  E17A 3620 4DCA A533 19BF

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCZ/K4NiBNyqUzGb8RAvigAJ42e4PVvJaOL/VKYp9xSpK6VmLUrQCbBK64
rPoJhPCEKWFBPdTyWhtfD/g=
=9m62
-----END PGP SIGNATURE-----