From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Testing the new VC code Date: Mon, 24 Nov 2014 21:50:54 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20141125025054.GA20793@thyrsus.com> References: <20141123215659.2CA0C382F79@snark.thyrsus.com> <874mtp58a9.fsf@fencepost.gnu.org> <20141124083310.GA29913@thyrsus.com> <87zjbh3r98.fsf@fencepost.gnu.org> <20141124094929.GA32148@thyrsus.com> <87k32k51ka.fsf@fencepost.gnu.org> <20141124104616.GA1744@thyrsus.com> <87fvd8steg.fsf@gmx.de> <20141124130355.GA5432@thyrsus.com> <87bnnwqtfi.fsf@gmx.de> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416883890 5605 80.91.229.3 (25 Nov 2014 02:51:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Nov 2014 02:51:30 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 25 03:51:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xt6Dr-0008Pe-0L for ged-emacs-devel@m.gmane.org; Tue, 25 Nov 2014 03:51:23 +0100 Original-Received: from localhost ([::1]:55247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xt6Dq-0001KP-6g for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 21:51:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xt6DY-0001KE-5e for emacs-devel@gnu.org; Mon, 24 Nov 2014 21:51:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xt6DT-0001Yl-TL for emacs-devel@gnu.org; Mon, 24 Nov 2014 21:51:04 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:39763 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xt6DP-0001YX-8M; Mon, 24 Nov 2014 21:50:55 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id A8FBB382BFD; Mon, 24 Nov 2014 21:50:54 -0500 (EST) Content-Disposition: inline In-Reply-To: <87bnnwqtfi.fsf@gmx.de> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178213 Archived-At: Michael Albinus : > 1. Test: Check a file not under vc > > Your version is even a little bit faster. IIRC, the heuristic functions > weren't such good for Tramp, because they have used process calls > instead of file existence checks. Tramp internal optimizations do not > work then. Yes, that is one reason I was expecting the change to make little difference > 2. Test: Check a file under CVS control. The CVS repository is on > savannah > > Your version is not bad, but a factor of 13 slower. So if you have a > slow connection to your CVS repository, caching would help. This is the only case turned up in your testing that concerns me. It may be an argument for restoring some of the state-heuristic machinery in the CVS back end only. Or maybe not - because of your git results I'd need a bit more persuading. See below. > 4. Test: Check a file under Git control > > Again, your version is slower (15%). More surprising, both versions are > much slower than with Bzr. I guess one could improve the code for git. This suggests that there is significant noise in your profiling, because the git back end had no local caching to begin with. There must be some external source of variation. I suspect that your test is quite sensitive to short-term fluctuations in network latency and a lot of what you were measuring was actually that. Otherwise the checkin running a bit *faster* would be hard to explain. In any case, none of the differences seem worth getting excited about. I'll keep an eye on CVS latency, but I won't reintroduce complexity against it unless we get complaints from real users. With response times of a quarter second I think that is unlikely - it's not that far above the minimum ergonomic threshold of 0.17sec below which humans simply cannot notice latency at all. (A spinal reflex arc is about 0.10 seconds. Human nerve conduction velocity - the "speed of thought" - is not actually very high.) -- Eric S. Raymond