Re: cvs commit: apr CHANGES apr-config.in
On Mon, Aug 30, 2004 at 04:19:22AM -, [EMAIL PROTECTED] wrote: jerenkrantz2004/08/29 21:19:22 Modified:.Tag: APR_0_9_BRANCH CHANGES apr-config.in Log: If available, use 'readlink -f' to resolve symlinks in apr-config. This has broken the build on the various Linuxes that have a readlink that doesn't support -f. I'll backport the proper fixes for this stuff from HEAD.
Re: cvs commit: apr CHANGES apr-config.in
--On Wednesday, September 1, 2004 7:15 AM +0100 Joe Orton [EMAIL PROTECTED] wrote: This has broken the build on the various Linuxes that have a readlink that doesn't support -f. I'll backport the proper fixes for this stuff from HEAD. Oh, that sucks. Sorry. Out of curiosity, when was 'readlink -f' introduced? Both Debian and RHEL have it (that's all I have access to). I thought this would be an easier way to fix it than backporting the whole set of changes from HEAD. Thanks. I'll let you backport since you did those changes initially. ;-) -- justin
Making pool 3 times faster on WIN32
Hi,
If my tests are correct the following patch makes the pool allocation
tree times faster on WIN32 (at least for 1 million
32 bytes allocations).
Not sure what's the total httpd's time spent for palloc,
but I suppose it's quite a large value.
Regards,
MT.
Index: apr_pools.c
===
RCS file: /home/cvspublic/apr/memory/unix/apr_pools.c,v
retrieving revision 1.206
diff -u -r1.206 apr_pools.c
--- apr_pools.c 17 Jun 2004 14:13:58 - 1.206
+++ apr_pools.c 1 Sep 2004 17:25:44 -
@@ -58,6 +58,14 @@
#define TIMEOUT_USECS300
#define TIMEOUT_INTERVAL 46875
+#if APR_POOL_DEBUG
+#define APR_HAS_WIN32_HEAP 0
+#else
+#ifdef _WIN32
+#define APR_HAS_WIN32_HEAP 1
+#endif
+#endif
+
/*
* Allocator
*/
@@ -71,6 +79,9 @@
#endif /* APR_HAS_THREADS */
apr_pool_t *owner;
apr_memnode_t *free[MAX_INDEX];
+#if APR_HAS_WIN32_HEAP
+HANDLE heap;
+#endif
};
#define SIZEOF_ALLOCATOR_T APR_ALIGN_DEFAULT(sizeof(apr_allocator_t))
@@ -84,12 +95,22 @@
{
apr_allocator_t *new_allocator;
+#if APR_HAS_WIN32_HEAP
+HANDLE heap;
+
+heap = HeapCreate(HEAP_NO_SERIALIZE, 64 * 1024, 0);
+if ((new_allocator = HeapAlloc(heap, HEAP_ZERO_MEMORY,
+ SIZEOF_ALLOCATOR_T)) == NULL)
+return APR_ENOMEM;
+new_allocator-heap = heap;
+#else
*allocator = NULL;
if ((new_allocator = malloc(SIZEOF_ALLOCATOR_T)) == NULL)
return APR_ENOMEM;
memset(new_allocator, 0, SIZEOF_ALLOCATOR_T);
+#endif
new_allocator-max_free_index = APR_ALLOCATOR_MAX_FREE_UNLIMITED;
*allocator = new_allocator;
@@ -99,6 +120,9 @@
APR_DECLARE(void) apr_allocator_destroy(apr_allocator_t *allocator)
{
+#if APR_HAS_WIN32_HEAP
+HeapDestroy(allocator-heap);
+#else
apr_uint32_t index;
apr_memnode_t *node, **ref;
@@ -111,6 +135,7 @@
}
free(allocator);
+#endif
}
#if APR_HAS_THREADS
@@ -289,8 +314,13 @@
/* If we haven't got a suitable node, malloc a new one
* and initialize it.
*/
+#if APR_HAS_WIN32_HEAP
+if ((node = HeapAlloc(allocator-heap, HEAP_NO_SERIALIZE, size)) ==
NULL)
+return NULL;
+#else
if ((node = malloc(size)) == NULL)
return NULL;
+#endif
node-next = NULL;
node-index = index;
@@ -360,7 +390,11 @@
while (freelist != NULL) {
node = freelist;
freelist = node-next;
+#if APR_HAS_WIN32_HEAP
+HeapFree(allocator-heap, HEAP_NO_SERIALIZE, node);
+#else
free(node);
+#endif
}
}
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Fwd: Re: Making pool 3 times faster on WIN32]
At 01:32 PM 9/1/2004, Mladen Turk wrote: Bill Stoddard wrote: Not sure what's the total httpd's time spent for palloc, but I suppose it's quite a large value. I saw no significant difference serving a 500 byte file: Keep in mind that the whole idea behind APR pools is to minimize calls to the native memory allocators (malloc/heap). If your benchmark recycled the pool each time you did an allocation, the 3x difference is not suprising, but that is a somewhat artifical benchmark imho. Yes, it seems that the number of times the allocator is actually calling malloc/free is low compared to the palloc calls. Yes - httpd tends to perform a rather small number of malloc/free operations - well, if you aren't using some add-in modules such as svn which have more atomic memory units to free up. Sorry for the noise :) I don't consider it noise. Please don't dismiss this patch soely on the basis that it offers small benefit to httpd. There are other applications that rely on APR, I'd love to see the concept of this patch incorporated. I'll spend cycles on it myself after I finish reviewing the rather large list of patches you recently submitted :) Bill
Re: cvs commit: apr CHANGES apr-config.in
On Tue, Aug 31, 2004 at 11:19:53PM -0700, Justin Erenkrantz wrote: --On Wednesday, September 1, 2004 7:15 AM +0100 Joe Orton [EMAIL PROTECTED] wrote: This has broken the build on the various Linuxes that have a readlink that doesn't support -f. I'll backport the proper fixes for this stuff from HEAD. Oh, that sucks. Sorry. Out of curiosity, when was 'readlink -f' introduced? Both Debian and RHEL have it (that's all I have access to). It looks like RHL9 and later, where /usr/bin/readlink is the GNU coreutils implementation, which does support -f and -n. In earlier releases readlink was part of the teTeX package, strangely. joe
