Re: [reSIProcate] gperf updates? Remove some hackery.

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	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