Re: LTO - shall we? Fwd: [med-svn] [Git][med-team/vsearch][master] Added link-time optimisation
Hi,
On Sat, Aug 03, 2019 at 03:19:30PM +0200, Steffen Möller wrote:
> Hello,
>
> Yesterday I revisited the packaging of vienna-rna and saw that upstream
> already works with link-time optimisation. That is a good thing,
> speed-up is often enormous as in 20% - depending on how cluttered the
> source code is, so this saves both time and energy. This works by
> reducing code to execute as in
>
> $ dpkg -c ../vsearch_2.13.6-2_amd64.deb # with LTO
> ...
> -rwxr-xr-x root/root 334344 2019-08-03 14:59 ./usr/bin/vsearch
> ...
>
> $ dpkg -c ../vsearch_2.13.6-1_amd64.deb # current version
> ...
> -rwxr-xr-x root/root 362064 2019-08-03 14:55 ./usr/bin/vsearch
> ...
That's only space on hard disk. I do not think that this will matter
much for our users. I think we should at least run the test suite
(which is currently not in autopkgtest since we did not finished the
vsearch-data package.
> So there is some 8% less code - and with a bit of luck this is primarily
> where there computation is.
>
> I have not uploaded that -2 version. This is since I am not the regular
> maintainer. That is Tim.
As far as I know Tim claimed himself inactive. His last commit to any
package of Debian Med was 2015-09-14. I'm considering to face the
thruth and remove Tim from any of our packages. So feel free to replace
Tim by your own idea.
> But it doubt that he wants to have much of say
> on this, the package is more team maintained. So I ask the team: Shall
> we add LTO when we can feel like it?
I do not think that disk space is worth the effort. As far as I read
the thread you opened on debian-devel the general consensus was that LTO
is not a good idea in some cases. So please base your arguing on a gain
of speed by reproducing the identical results to the non-LTO version.
Just saving some disk space is not really a good argument to risk
defunctional software, IMHO.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: