On 27.03.2013 22:57, jaillet...@apache.org wrote:
> Author: jailletc36
> Date: Wed Mar 27 21:57:44 2013
> New Revision: 1461869
> 
> URL: http://svn.apache.org/r1461869
> Log:
> Be more clever when allocating memory for log item to be escaped.
> This should save about 70-100 bytes in the request pool with the default 
> config.
> 
> Modified:
>     httpd/httpd/trunk/server/util.c
> 
> Modified: httpd/httpd/trunk/server/util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=1461869&r1=1461868&r2=1461869&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/server/util.c (original)
> +++ httpd/httpd/trunk/server/util.c Wed Mar 27 21:57:44 2013
> @@ -1850,12 +1850,26 @@ AP_DECLARE(char *) ap_escape_logitem(apr
>      char *ret;
>      unsigned char *d;
>      const unsigned char *s;
> +    int length = 0;
>  
>      if (!str) {
>          return NULL;
>      }
>  
> -    ret = apr_palloc(p, 4 * strlen(str) + 1); /* Be safe */
> +    /* First, compute the space needed for the escaped string.
> +     * This could be tweaked a bit for '\b', '\n'... These characters
> +     * should not be common, so do not bother. */
> +    s = (const unsigned char *)str;
> +    for (; *s; ++s) {
> +        if (TEST_CHAR(*s, T_ESCAPE_LOGITEM)) {
> +            length += 4;        /* for '\\' + c2x() */
> +        }
> +        else {
> +            length++;
> +        }
> +    }
> +    
> +    ret = apr_palloc(p, length + 1);
>      d = (unsigned char *)ret;

Here we treat CPU against memory. AFAIK this function is in the hot code
path, because it is used for many of the fields used in the default
access log format and also in many custom ones. All other uses seem to
be either trace log messages, some (few) error log messages and
mod_status output. For those cases I think neither the CPU nor the
Memory differences are important.

In the access log case it seems the typical fields which are run through
ap_escape_logitem() should rarely contain characters to escape. So an
alternative strategy would be to simply copy the string if we don't find
a character to escape. The second check for each char is not necessary then.

A quick draft patch is at

http://people.apache.org/~rjung/patches/ap_escape_logitem_enhanced.patch

It compiles, but I haven't really tested it. You get the idea though.

In the case of no escapes, it should be quite a bit faster. In the case
of escapes it shouldn't make a noticeable difference in any direction.

Regards,

Rainer

Reply via email to