Created attachment 27414 [details] Proposed patch Hi, in 'modules/metadata/mod_usertrack.c', the function 'make_cookie' can be improved. Actually, it uses a hard coded 1024 bytes buffer that is heap allocated. At the end of the function, this buffer is copied into a pool with a 'apr_pstrdup' call when doing the final 'apr_table_setn' call. So, if the buffer was directly allocated within the pool, we could get reed of the intermediate buffer. What this patch actually does is : - remove the 'cookiebuf' buffer - allocate 'cookiebuf' directly in the pool with calling 'apr_psprintf' instead of 'apr_snprintf' - turns a 'apr_psprintf(r->pool, "%s=%s...)' call to an equivalent 'apr_pstrcat' call which is faster (1) - move this before 'if (cls->expires)' because the same allocation is done in the 2 paths of the 'if' (1) - avoid calling 'apr_pstrdup' when setting 'cookiebuf' in the table as it is now already allocated in the right location. (1) : this part is unrelated to the removal of the buffer, but was already proposed, accepted but never applied. See https://issues.apache.org/bugzilla/show_bug.cgi?id=42008 for that. Finally, this patch is *not* tested and is proposed as-is, as I'm not able to compile httpd for now on my machine. Best regards, Christophe JAILLET
In fact, I should speak of stack instead of heap...
Must be revisited due to some change in trunk. Maybe should be closed now that the 1024 bytes buffer is gone. Rearranging the code in 'make_cookie' could still be a win. It could avoid the allocation of a buffer via apr_snprintf which is then apr_pstrdup'ed at the end of the function. This would save one of the 2 allocations which are strings build with: "%x.%" APR_UINT64_T_HEX_FMT. Would you like me to propose an updated patch ?