Subject: bug#13472: [PATCH] libtool: speed up by pre-cutting sed's input by dd

From: Pavel Raiskup <[email-masked]>
Date: Fri, 21 Feb 2014 15:03:24 +0100

Peter, sorry for the delay,

On Thursday, February 13, 2014 20:52:59 Peter Rosin wrote:
> On 2014-02-13 18:57, Peter Rosin wrote:
> > On 2014-02-12 16:22, Nick Bowler wrote:
> >> On 2/11/14, Peter Rosin <[email-masked]> wrote:
> >>> Ok Pavel, first of all, sorry for the "smallish" delay in handling
> >>> your request, and Nick, are you able to test this patch?
> >> [...]
> >>> Does my version work? The testsuite behaves OK for me, but other than
> >>> that I haven't tested.
> >>
> >> Patch seems to work!
> > 
> > Ok, everybody seems happy. But not me, not 100% anyway. This introduces
> > an extra fork, and AFAICT, the "extra protection" is only needed when
> > func_lalib_p is called from func_ltwrapper_script_p. Should we perhaps
> > have a separate implementation in func_ltwrapper_script_p instead of
> > simply calling func_lalib_p?
> > 
> > Maybe we could also lose the "sed -e 4q" part when dd limits the size?

IMHO very good idea ^^^.  Cutting some line in the middle should not be a
problem after 4kB of characters, so why not.

> *snip* outline, real patch attached instead...
> 
> Now, which patch should I push?
> 
> The old [1]:
> libtool: speed up lalib detection in execute mode
> 
> or the new?
> libtool: speed up ltwrapper_script detection in execute mode
> 
> I like the latter better and will push that soonish. Unless...

I would use  something in the middle.  I really don't like code
duplication and looking at the two functions, the grep work is clearly
duplicated in [v2].  So as you proposed, use either 'dd' or 'sed'.  But
basically, I would take any of the two patches (as they work) rather than
make you to work on this too much - so I am OK if you choose what you like
better.

Thanks for your work,
Pavel