From owner-svn-src-all@FreeBSD.ORG Mon Dec 26 20:43:27 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8DC4B106566C; Mon, 26 Dec 2011 20:43:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EB6AB1560A2; Mon, 26 Dec 2011 20:43:08 +0000 (UTC) Message-ID: <4EF8DC5B.9070404@FreeBSD.org> Date: Mon, 26 Dec 2011 12:43:07 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Marius Strobl References: <201112241216.pBOCGd1H012696@svn.freebsd.org> <4EF645D2.8080407@FreeBSD.org> <20111226102820.GT90831@alchemy.franken.de> In-Reply-To: <20111226102820.GT90831@alchemy.franken.de> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r228857 - in head/usr.bin: . csup X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 20:43:27 -0000 On 12/26/2011 02:28, Marius Strobl wrote: > On Sat, Dec 24, 2011 at 01:36:18PM -0800, Doug Barton wrote: >> On 12/24/2011 04:16, Marius Strobl wrote: >>> On FreeBSD just use the MD5 implementation of libmd rather than that of >>> libcrypto so we don't need to relinquish csup when world is built without >>> OpenSSL. >> >> Did you benchmark this at all? I agree that keeping csup available >> absent openssl is a good goal, but csup is a prototypical "tool that >> does the same thing many thousands of times" so even tiny regressions >> could add up to a large cost in wall clock time. > > Well, in a real world test updating the same base on an amd64 machine > connected to the Internet Adding a network connection to the test is almost certainly going to obscure the results beyond utility. The appropriate way to test this would be to create a binary out of the md5 routine in csup, and link it alternately with libcrypto and libmd. Then for each version run it against the src tree (or ports, either way) 10 times. Discard the first and last, and then plot the results with ministat. > If we really cared about the MD5 performance of applications linked > against libmd (including md5(1)), we should just optimize that MD5 > implementation rather than working around it. If it turns out that it's slower, that's a valid option as long as it happens soon'ish. :) > Also for csup, fixing the problem that is causing it to fetch whole > files over and over again likely would improve its performance way > more than using a different MD5 implementation could do. "There are other problems with this program" is not a good reason to add a pessimization. But let's find out if it is a pessimization before we worry about that. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/