From owner-cvs-all@FreeBSD.ORG Fri Jan 27 03:21:56 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.ORG Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B77916A420; Fri, 27 Jan 2006 03:21:56 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id C29B443D45; Fri, 27 Jan 2006 03:21:55 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id k0R3LsH4058090; Fri, 27 Jan 2006 06:21:54 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id k0R3Lspu058089; Fri, 27 Jan 2006 06:21:54 +0300 (MSK) (envelope-from ache) Date: Fri, 27 Jan 2006 06:21:54 +0300 From: Andrey Chernov To: Jason Evans Message-ID: <20060127032154.GA58032@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Jason Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200601270236.k0R2ai2x067283@repoman.freebsd.org> <20060127025150.GA57825@nagual.pp.ru> <6B47D688-0A7D-421F-9830-9493EC375307@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B47D688-0A7D-421F-9830-9493EC375307@FreeBSD.ORG> User-Agent: Mutt/1.5.11 Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 03:21:56 -0000 On Thu, Jan 26, 2006 at 07:02:17PM -0800, Jason Evans wrote: > Unfortunately, run-time checks for the debugging features are > expensive, since the debugging code is scattered throughout > malloc.c. This pretty much mandates compile-time configuration, for > performance reasons. Checking one integer many times is definitely not so expensive, as following many debugging asserts and even mutex locks I see in statistics code. I mean if (debug) {...lots of asserts...} and if (statistic) {..even locks...} Even most of single line statistic assignments are more complex than checking integer, because of struct/array indexes calculation. > consensus to do so. How much performance difference is the debug/ > stats code making for you? I've only been disabling debug/stats for > benchmarking purposes, so I don't have a good feel for how much it > impacts overall system performance. I can't run benchmark right now, but last time I see, I feel slowdown. Perhaps human error, can't tell for sure right now. -- http://ache.pp.ru/