On Apr 9, 2009, at 3:32 PM, Bill Stoddard wrote:
Jim Jagielski wrote:
On Apr 8, 2009, at 8:33 PM, Jeff Trawick wrote:
On Wed, Apr 8, 2009 at 11:00 AM, Jim Jagielski j...@jagunet.com
wrote:
On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote:
Yep... I will try to recreate on Ubuntu in
On Apr 8, 2009, at 8:33 PM, Jeff Trawick wrote:
On Wed, Apr 8, 2009 at 11:00 AM, Jim Jagielski j...@jagunet.com
wrote:
On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote:
Yep... I will try to recreate on Ubuntu in addition to the
OS X testing.
OK This seems unrelated (maybe) to the new
Jim Jagielski wrote:
On Apr 8, 2009, at 8:33 PM, Jeff Trawick wrote:
On Wed, Apr 8, 2009 at 11:00 AM, Jim Jagielski j...@jagunet.com wrote:
On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote:
Yep... I will try to recreate on Ubuntu in addition to the
OS X testing.
OK This seems
On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote:
Yep... I will try to recreate on Ubuntu in addition to the
OS X testing.
OK This seems unrelated (maybe) to the new pool...
The cause for the slowdown was due to httpd constantly dumping
core. Looking at the cores, I see
(gdb) where
#0
On Wed, Apr 8, 2009 at 11:00 AM, Jim Jagielski j...@jagunet.com wrote:
On Mar 30, 2009, at 3:02 PM, Jim Jagielski wrote:
Yep... I will try to recreate on Ubuntu in addition to the
OS X testing.
OK This seems unrelated (maybe) to the new pool...
The cause for the slowdown was due to
Mladen Turk wrote:
So, it's been proven that the new apr pool
doesn't perform well except on some obscure platforms
with third-party libraries.
Just did some more profiling on the new apr-pool code
inside httpd. I've simply
#undef malloc
#undef calloc
and add size and number of call counters
So, it's been proven that the new apr pool
doesn't perform well except on some obscure platforms
with third-party libraries.
Further more the new pool broke the API since Paul
decided he doesn't need the unmanaged pools ;)
Since there were absolutely nothing wrong with the old
code can we have
On Wed, Apr 1, 2009 at 10:03 AM, Mladen Turk mt...@apache.org wrote:
So, it's been proven that the new apr pool
doesn't perform well except on some obscure platforms
with third-party libraries.
Further more the new pool broke the API since Paul
decided he doesn't need the unmanaged pools ;)
Sander Striker wrote:
... and yes, can we get rid of the POOL_DEBUG.
It totally breaks the apr concept of a clean API,
and doubles the pool code without (at least to me)
any good reason.
Darn, you almost had me there (April Fools!). Just in case you were
being serious, the pool debug code
OK... I've tested httpd-trunk (head) with apr-1.4 (head)
and apr-trunk (head). This is on OS X (10.5.6) with both
worker and event MPM. I've also tried different default
mutexes (OSX is SysV, but I've also forced fcntl) and the
rub is that when using the test framework, the
t/module/dir.t test is
On 03/30/2009 08:20 PM, Jim Jagielski wrote:
OK... I've tested httpd-trunk (head) with apr-1.4 (head)
and apr-trunk (head). This is on OS X (10.5.6) with both
worker and event MPM. I've also tried different default
mutexes (OSX is SysV, but I've also forced fcntl) and the
rub is that when
On Mar 30, 2009, at 2:57 PM, Ruediger Pluem wrote:
On 03/30/2009 08:20 PM, Jim Jagielski wrote:
OK... I've tested httpd-trunk (head) with apr-1.4 (head)
and apr-trunk (head). This is on OS X (10.5.6) with both
worker and event MPM. I've also tried different default
mutexes (OSX is SysV, but
Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can simply revert it or we add tcmalloc as a compile-time
option if
On Mar 26, 2009, at 11:24 AM, Joe Orton wrote:
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we
duplicate in
APR pools. By
On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of
time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can simply revert it or we add tcmalloc as a
On 27.03.2009 14:00, Jim Jagielski wrote:
On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can
Jim Jagielski wrote:
On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can simply revert it or we
On Mar 27, 2009, at 11:17 AM, Mladen Turk wrote:
Jim Jagielski wrote:
On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of
time.
If we can't beat the old system by COB tomorrow
On Fri, Mar 27, 2009 at 4:40 PM, Jim Jagielski j...@jagunet.com wrote:
On Mar 27, 2009, at 11:17 AM, Mladen Turk wrote:
Jim Jagielski wrote:
On Mar 26, 2009, at 7:51 PM, Justin Erenkrantz wrote:
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental
Just did some quick bench of the current trunk,
and the results are not very much encouraging.
static void test_performance(abts_case *tc, void *data)
{
apr_status_t rv;
int i;
void *m;
apr_time_t end, now = apr_time_now();
for (i = 0; i 100; i++) {
apr_pool_t
Mladen Turk wrote:
Just did some quick bench of the current trunk,
and the results are not very much encouraging.
Inner loops are even worse.
Calling 1 x 32 bytes allocations
is more then 10 times slower.
This takes less then a second on my box to finish
with apr 1.4 and 11 seconds with
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs ` poolspeed.c
poolspeed.c
OSX 10.5.6 (MBP, Intel Core 2 2.8 Ghz):
APR 1.3: 66583433
APR 2.0: 211770082 (+318%)
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Solaris 10 (sparc t2000; eos.apache.org):
APR 1.3: 425809665
APR 2.0: 1344579431 (+315%)
I'd be interested in
Paul Querna wrote:
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs `
Paul Querna wrote:
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs `
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
APR 2.0: 214131712 (-22%)
I think we should consider bundling tcmalloc, or making it a compile
time option.
This shows that many
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication, and relying on malloc
Paul Querna wrote:
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
APR 2.0: 214131712 (-22%)
I think we should consider bundling tcmalloc, or making it a compile
time
Joe Orton wrote:
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication, and relying
Joe Orton wrote:
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication,
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
Paul Querna wrote:
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
APR 2.0: 214131712 (-22%)
I think we
Paul Querna wrote:
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
We have JNI bindings for Subversion, which uses APR, whose packaging and
compilation options we don't control. *boom*
That is only talking about loading tcmalloc using the normal library.
you can compile
Paul Querna wrote:
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
Paul Querna wrote:
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
On Thu, 2009-03-26 at 21:32 +0100, Branko Čibej wrote:
Maybe it's just me, but all that seems like a monumental waste of
time.
I don't really have the right to comment here, because I put zero effort
into this, but it does look that way, doesn't it?
On the other hand, there are patches that
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can simply revert it or we add tcmalloc as a compile-time
option if it's not too complex to use that. Either
35 matches
Mail list logo
