Sander Striker wrote:
Hi,
Just raising this again. This time I'll ask differently: Is anyone opposed to adding this? [feedback please]
I know Ian wants this badly. I can go either way. I would really like to see some perf comparisons with and without it to see if it doesn't do too much damage to performance (or if it does at all in a measurable fashion).
Sander
+1
I think a small performance penalty is better than keeping unused allocated VM around.
From: Sander Striker [mailto:[EMAIL PROTECTED] Sent: 21 March 2002 09:13
The free is triggered on either apr_pool_clear or apr_pool_destroy,From: Bill Stoddard [mailto:[EMAIL PROTECTED] Sent: 19 March 2002 21:36
This could be quite useful for mod_*_cache. What triggers the free?
when the blocks in the pool are returned to the allocator (using
apr_allocator_free()). When adding a block to the freelist causes
the freelist to be larger than then threshold (set with apr_allocator_set_max_free()), the block will be free()d instead
of added.
The default is to have max_free be 0, which translates to unlimited, which is the current behaviour.
Ofcourse this patch will come at a small performance penalty, but I'm not sure if it is measurable.
Bill
Sander
----- Original Message ----- From: "Sander Striker" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 19, 2002 2:45 PM
Subject: [PATCH] Maximum free memory in an allocator OR: hifree, revisited
Hi,
Keep getting the question if the hifree patch is going in. So, decided to revisit that patch and implement it now we have the allocators.
For those who didn't follow that thread: This patch allows the programmer to set a maximum amount of free bytes allowed on the allocators freelist. Anything over it will be free()d back to the system.
Thoughts?
Sander
-- Brane Čibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
