Date: Fri, 27 Jan 2006 06:21:54 +0300 From: Andrey Chernov <ache@FreeBSD.ORG> To: Jason Evans <jasone@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c Message-ID: <20060127032154.GA58032@nagual.pp.ru> In-Reply-To: <6B47D688-0A7D-421F-9830-9493EC375307@FreeBSD.ORG> References: <200601270236.k0R2ai2x067283@repoman.freebsd.org> <20060127025150.GA57825@nagual.pp.ru> <6B47D688-0A7D-421F-9830-9493EC375307@FreeBSD.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060127032154.GA58032>