Using different hash algorithm in purple_util_get_image_checksum()

[Mark Doliner]

On Fri, Jul 3, 2009 at 10:33 PM, Paul Aurich<paul at darkrain42.org> wrote:
> And Richard Laager spoke on 07/01/2009 10:41 PM, saying:
>> On Wed, 2009-07-01 at 01:29 -0700, Mark Doliner wrote:
>>> Vijay from Meebo tells me that he seems to
>>> remember the sha-1 implementation in glib 2.16 is much faster than the
>>> one in our cipher.c.
>>
>> If this is true and it would be possible, it'd be nice if we just called
>> that from our cipher API when libpurple is built against glib >= 2.16.
>
> I've attached a patch that will conditionally use Glib for MD5, SHA1, and
> SHA256 when available. `make check` passes with all three and it seems to
> work fine.
>
> In a very simplistic benchmark, I loaded the largest image in my
> .purple/icons/ (32KiB) and calculated the SHA1sum 100,000 times (and stuck
> a g_str_equal() in there just to make sure gcc didn't get cute with me). On
> my AMD Athlon 64 4400+, the cipher.c implementation took about 41 seconds
> and glib's implementation took about 14 seconds.
>
> Anyone have any problems with my checking this in? The only thing left to
> do is deal with the issue in adding data to the checksum, where GChecksum
> uses a gssize and we use a gsize for the length, which will be bad when I
> decide I want to use Pidgin to calculate the checksum for my 3GB file
> (after I dig up a 32-bit system).

Looks great to me.  I have no problems with you checking this in.  It
would be be nice to be able to use a gsize for file size, although we
should probably be using a 64-bit type for that.  At some point in the
distance future we'll probably make file transfer work on more
protocols, and by the time that happens it might be common for people
to want to transfer 5GB files :-P

-Mark