Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of poirier@pobox.com designates
 208.72.237.35 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject
	:in-reply-to:references:date:message-id:mime-version
	:content-type; q=dns; s=sasl; b=UjThCM9hQR4JV2g0AY9e1xUH1Gio4Eo/
	fZmBKm9M8nc1G75sCsc4ERtkYIZ34/0AB+tCus72rPxBHZqhMmxuEuIwMY1jrm4t
	1fzD206RIvDYXGJ49oUdhCRD5jMz4sbxFQYZWvNHEIsMSOPaI5m24bnHtA9mGu06
	PMEcW2Dw+u8=
From: Dan Poirier <poirier@pobox.com>
To: dev@httpd.apache.org
Subject: Re: [PATCH] LogLevel refactoring part 1
In-Reply-To: <201002030922.21616.sf@sfritsch.de> (Stefan Fritsch's message of
 "Wed, 3 Feb 2010 09:22:21 +0100")
References: <201002030922.21616.sf@sfritsch.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (darwin)
Date: Fri, 05 Feb 2010 09:39:13 -0500
Message-ID: <yua8wb7ycfi.fsf@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Wed, Feb  3, 2010, at 03:22:21 AM, Stefan Fritsch <sf@sfritsch.de> wrote:

> ap_log_error_wrapper.diff:
> On C99 compilers, avoid argument setup and function call overhead if 
> the log message will be discarded anyway. Also allow to disable higher 
> loglevels at compile time by defining APLOG_MAX_LOGLEVEL.
> On pre-C99 compilers, it should just work like before.

This seems like a reasonable thing to do.  I can't comment on the
correctness, not being up on C99.  

Is there some server coding convention calling for trailing _ and __ on
the macro and function names?  If not, my personal preference would be
something more meaningful when reading the code.

I'd love to know difference this makes in processor usage under load,
between running with loglevel debug and something lower.  Saving a
function call for every logging line on the main path could be a big
win.

> loglevel_trace.diff:
> Introduce additional log levels trace1 ... trace8 above the debug 
> level.

If we're thinking about expanding control of debug messages, my
inclination would be to work toward allowing independent control of
messages from different parts of the code or about different things,
rather than a strict series of increasing levels of logging.  E.g. maybe
today I'd like to see all debug trace from authentication, but tomorrow
just see SSL stuff.

Dan