[reSIProcate] gperf updates? Remove some hackery.

[Byron Campen]

	The performance gain would be very slight. I feel that there is  
enough value in being able to regenerate the table when we add a  
header/param/method to make me want to stick with a gperf-generated  
hash function. I don't think that doing it every build is worthwhile  
though.

Best regards,
Byron Campen

>
> I always been a fan of removing the gperf dependency all together.  
> If you are willing to use just a little bit more memory for the  
> tables, it is pretty trivial to get more or less any reasonable  
> hash function to not collide for some size table. I suspect that  
> making the table that much larger would be a drop in the bucket of  
> overall memory use in resip.
>
> On Oct 12, 2007, at 7:56 PM, Byron Campen wrote:
>
>> 	I think Jason is saying that most embedded systems won't have gperf
>> 3. I'm saying that the answer is to not build new hash functions
>> using the regular build. Put it aside as a separate script that can
>> be run independent of the regular build, and just have all the
>> generated files live in the repository. This would remove a build
>> dependency that is continually giving newcomers grief (always a good
>> thing), cut down on the complexity of the build system a little (also
>> good), and probably help performance a tiny bit (I imagine gperf will
>> generate slightly better code than our hacked-up scripts will).
>>
>> Best regards,
>> Byron Campen
>>
>>> I must be missing something. What does changing gperf have to do
>>> with embedded builds?
>>>
>>> Thanks
>>> A
>>>
>>> -----Original Message-----
>>> From: Byron Campen <bcampen at estacado.net>
>>> Date: Fri, 12 Oct 2007 21:21:30
>>> To:Jason Fischl <jason at counterpath.com>
>>> Cc:"Alan Hawrylyshen" <alan at polyphase.ca>,       "resiprocate-devel
>>> resiprocate-devel" <resiprocate-devel at list.resiprocate.org>
>>> Subject: Re: [reSIProcate] gperf updates? Remove some hackery.
>>>
>>> 	I would like to point out that generating fresh hash functions on
>>> every build is of limited value, especially considering the hoops  
>>> you
>>> have to jump through to add a method/header/parameter anyway.
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>> The only thing i'll point out is that this will break the build on
>>>> lots of embedded systems. What does it really buy us?
>>>>
>>>> On 10/9/07, Byron Campen <bcampen at estacado.net> wrote:
>>>>> 	I'm all for it.
>>>>>
>>>>> Best regards,
>>>>> Byron Campen
>>>>>
>>>>>> I've noticed that the newer versions of gperf permit case-
>>>>>> insensitive
>>>>>> hashes to be generated. I find this oddly satisfying given  
>>>>>> that the
>>>>>> GNU/FSF position on this previously was 'over my dead body'.
>>>>>>
>>>>>> What are peoples' feelings around updating our build process to
>>>>>> leverage gperf 3.X and remove the hackery that edits the  
>>>>>> output of
>>>>>> the hash function generators?
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Alan
>>>>>>
>>>>>> Alan Hawrylyshen
>>>>>> a l a n a t p o l y p h a s e d o t c a
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> resiprocate-devel mailing list
>>>>>> resiprocate-devel at resiprocate.org
>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel