Re: [reSIProcate] gperf updates? Remove some hackery.
I like Byron's approach - only running gperf if you touch the headers or
parameters.
Scott
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron Campen
> Sent: Tuesday, October 16, 2007 9:00 AM
> To: Cullen Jennings
> Cc: resiprocate-devel resiprocate-devel; Jason Fischl
> Subject: Re: [reSIProcate] gperf updates? Remove some hackery.
>
> 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@xxxxxxxxxxxx>
> >>> Date: Fri, 12 Oct 2007 21:21:30
> >>> To:Jason Fischl <jason@xxxxxxxxxxxxxxx>
> >>> Cc:"Alan Hawrylyshen" <alan@xxxxxxxxxxxx>,
"resiprocate-devel
> >>> resiprocate-devel" <resiprocate-devel@xxxxxxxxxxxxxxxxxxxx>
> >>> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> >>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >>>>>
> >>>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> resiprocate-devel mailing list
> >>> resiprocate-devel@xxxxxxxxxxxxxxx
> >>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >>
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxx
> >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel