apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <s.stri...@striker.nl>
Subject Re: apr_pools hairsplitting
Date Tue, 17 Jul 2007 14:44:02 GMT
On 7/11/07, Davi Arnaut <davi@haxent.com.br> wrote:
> Hi,
>
> The current apr_pools.c file is a serious case of "spaghetti" code
> (ifdefs, debug and non-debug mixed, etc), making it hard to read f not
> impossible (subtle changes, catastrophic impact).

:-)  Have a look through the history of that file, just for fun :-D.

> In order to increase the overall readability and foster future
> improvements, I've separated the apr_pools.c file into more sane and
> self contained files:

My $0.02 is that comments would go a long way; it's the department where
I have been lacking.  Together with the apr_pool_free() function that never
actually made it into the codebase...

[...]
> Comments?

Splitting allocators and pools is very likely going to be a bad idea because
of inlining.  Other functionality you can likely split out.  I'm a bit
wary about
splitting out psprintf as that too hooks in very tightly with the allocation
logic.

Be very careful with changes, as the performance impact can be quite vast.
While we were working on this code, Brian Pane and others were doing
comparison tests between builds.

Cheers,

Sander

Mime
View raw message