Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 22636 invoked by uid 500); 11 Jun 2002 12:44:46 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Delivered-To: moderator for dev@httpd.apache.org Received: (qmail 33227 invoked from network); 10 Jun 2002 08:48:14 -0000 Message-Id: <5.1.0.14.2.20020610113455.0480d5c8@localhost> X-Sender: zeev@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Jun 2002 11:46:46 +0300 To: "Sander Striker" From: Zeev Suraski Subject: Re: [PHP-DEV] RE: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter Cc: , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 09:03 AM 6/10/2002, Sander Striker wrote: >Why is PHP even using its own memory allocation scheme? It would be much >easier to just use pools and point out where it doesn't work for you. Because we don't want it depend on any underlying services which aren't available in all servers. We can say that in general, the no-free allocation scheme doesn't work at all with PHP, so the pool approach cannot be used. Even if we could use it, though, all of the services of the memory allocator are still necessary at the PHP level so we can provide them outside the scope of Apache 2. What we need for efficient thread-safe operation is a mechanism like the Win32 heaps - mutexless heaps, that provide malloc and free services on a (preferably) contiguous pre-allocated block of memory. The question is whether the APR allocators fall into that category: 1. Can you make them mutexless completely? I.e., will they never call malloc()? 2. They definitely do provide alloc/free services, we're ok there 3. As far as I can tell, they don't use a contiguous block of memory, which means more fragmentation... Zeev Zeev