From dev-return-1044-daniel=haxx.se@subversion.apache.org Fri Jan 8 23:19:59 2010 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id o08MJwv1027319 for ; Fri, 8 Jan 2010 23:19:59 +0100 Received: (qmail 60386 invoked by uid 500); 8 Jan 2010 22:19:53 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 60376 invoked by uid 99); 8 Jan 2010 22:19:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 22:19:53 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.220.209] (HELO mail-fx0-f209.google.com) (209.85.220.209) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 22:19:44 +0000 Received: by fxm1 with SMTP id 1so21543352fxm.36 for ; Fri, 08 Jan 2010 14:19:23 -0800 (PST) Received: by 10.223.98.19 with SMTP id o19mr3369914fan.82.1262989163296; Fri, 08 Jan 2010 14:19:23 -0800 (PST) Received: from ?172.31.13.157? (cpe-90-157-167-167.dynamic.amis.net [90.157.167.167]) by mx.google.com with ESMTPS id 19sm2312946fkr.18.2010.01.08.14.19.21 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jan 2010 14:19:21 -0800 (PST) Message-ID: <4B47AF68.8050004@xbc.nu> Date: Fri, 08 Jan 2010 23:19:20 +0100 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Greg Hudson CC: Paul Querna , Subversion Dev Subject: Re: Subversion in 2010 References: <4DF6734D-0402-4C2C-8D15-D6FE14265B0E@mail.utexas.edu> <4239a4321001081231g6e0599d0x6f1139017422a4cc@mail.gmail.com> <1262984048.19973.75.camel@ray> In-Reply-To: <1262984048.19973.75.camel@ray> X-Enigmail-Version: 0.96.0 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRF IhsbCy0qZjoVOVRoeFxSAIKBzXQiAKaibYiewnk7nn9z0qCTgL3i87Ep6Kx/+tHBsrE+zgAAAjZJ REFUOMvF0jFoE1EYB/CzjWlqIzaTjqVIBifRRWyG0t5iUqlLyFpCeXBgKg5yq6A4degUDJjoUDpc 1Qt4Ux94B11SOLB0KGS4discpbkORTCn9/m9d3fvLhXnvuHu3f+Xx/veyyfZfLSdZHzgicSfeyw4 JISwdz8FT6M8lM8Ceg385Dlhs+cC9sQCDn0B78QCogzwN+sxfHGOIXBbRGkNAM4cZymGtgNsDPgz cByxon3EEm1TLmvAlghoHOO3CZSa+IQ/vF6JV8tgKOMow78gRgL2/+EIvATOUtB3SSdMg4GXgrbn uk0uLiGdoCHKbX4E+t1FUTqn1AtIdPJebssDQ64YANSQyyaQNyUOFs0ijMsMFnOPTahPLXKYowtY 08MfCP7vR7hRnc5zmPK7CDYYbHcbC7tHuyFA94U/1LYZaJpu/sxACHMwvwZljTLY0TbNk4x+zuEt yC3MfCM6uSIvfwur0itFL4FA2Yal8BzLfnYV4EIGwEPAk7o5zIcnvzHMEjwJrrhAKK7on6IrsfRJ 7A53BhaK+CL7fj6+q/sPeOvcDTtoZTxpUYsFeIknrOXep3p3l7Ua+8sZ5FPQKyKwWi+DfROTU7ny C1/9UhpeY7K287WJCzbsNPQm2S6Yk4PSCNhWM2r3nD0K9liYb6yPgCRJhSzPrxUK0yUBVk1VX0lj s7MzGZyp0wImMK/e8rHbz2soL+O+2r1dxfGsAmBcx0lNjS/RUhlUC7gRn1wGMdQ7Vw1/AReW/RN3 xFWdAAAAAElFTkSuQmCC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Greg Hudson wrote: > On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote: > >> "Profile everything, be faster at everything" >> > > There are smart people who will disagree with me on this, but I'm not > sure the best tool for improving Subversion performance is a profiler. > Historically a lot of our performance issues have come from algorithmic > inefficiencies, particularly from code in libsvn_repos. You can get > maybe a 10-30% reduction in time on these operations by trying to > optimize the innermost bit of code which gets repeated over and over > again, but in some cases you can get an order of magnitude reduction in > time by fixing the algorithms. > > It's been too long for me to remember any specific examples, > unfortunately. > You'd be surprised. A long time ago I saw a profiler log that seemed to indicate we were spending 90% of our time in the delta combiner. I refused to believe what I saw and never looked closer. Then DannyB came along and showed how a simple succession of target copy operations could slow the delta combiner tremendously. That was a reality check with a vengeance. In my experience the trick is in reading profiler output correctly, and actually analysing more than the last three levels of the call graph before trying to optimize anything. -- Brane