Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71123
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.182 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuSzUvsQjyRUzjd2CcEuoPfpF_iZ2dOjHOr2cScc93Httw@mail.gmail.com>
References: <CA+9eiLtmUgWSZhoHgXy+UfiakGHG5RuJwP6o4txVsU76fRsDpQ@mail.gmail.com>
	<CAMUwpuSzUvsQjyRUzjd2CcEuoPfpF_iZ2dOjHOr2cScc93Httw@mail.gmail.com>
Date: Tue, 14 Jan 2014 20:45:02 +0400
Message-ID: <CA+9eiLsCpv2Lq1Kp7UqVKC=yB96NS_3r9u7QhiQ=XZSgT6UP7Q@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3818af0dc2d04eff0e952
Subject: Re: [PHP-DEV] New Memory Manager
From: dmitry@zend.com (Dmitry Stogov)

--001a11c3818af0dc2d04eff0e952
Content-Type: text/plain; charset=UTF-8

Of course I tried to plug jemalloc and tcmalloc but they make slowdown
instead of speedup, mainly because zend_alloc was especially designed for
PHP and also because they suffer from multi-threading support overhead. On
the other hand profiling PHP with oprofile I saw a lot of cache misses in
zend_alloc.c, especially because of linked list handling. So I tried to
combine the best from all approaches and then spend a couple of week tuning
it.

Thanks. Dmitry.



On Tue, Jan 14, 2014 at 6:50 PM, Julien Pauli <jpauli@php.net> wrote:

> On Tue, Jan 14, 2014 at 3:21 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> > Hi,
> >
> > Recently I took a look into jemalloc and tcmalloc internals and tried to
> > borrow some ideas. You may check the result at
> > https://github.com/dstogov/php-src/tree/xx_malloc. It's a dirty prove of
> > concept implementation of New Memory Manager for PHP. It was tested only
> on
> > Linux, release, non-ZTS build. It misses support for debug mode and ZTS
> > yet. The main advantage is small but consistent speed improvement on
> > real-life applications.
> >
> > I would appreciate if you bench it vs vanilla PHP-5.6 on your
> applications,
> > review the code from performance and security points of views, and come
> > with comments, ideas and criticism. (For example: may be someone would
> > suggest how to avoid check for USE_ZEND_ALLOC=0 to allow system malloc()
> > usage on each emalloc() call? How to reduce cost of statistics
> collection?)
> >
> > Currently, I'm not sure if 5% speed improvements costs the effort.
> >
> > The results of my benchmarks follow.
> >
> > Thanks. Dmitry.
> >
> >    *PHP-5.6 32-bit* zend_alloc xx_malloc Improvement  blog 105.6 109.7
> > 3.88%  drupal
> > 1625.0 1667.6 2.62%  fw 231.6 286.4 23.66%  hello 12048.4 11865.9 -1.51%
>  qdig
> > 464.4 495.3 6.65%  typo3 563.8 584.9 3.74%  wordpress 188.9 196.8 4.19%
>  xoops
> > 132.7 140.0 5.50%  scrum 181.6 192.7 6.11%  ZF1 Hello 1153.2 1228.4
> 6.52%  ZF2
> > Test 263.0 275.5 4.75%
>
> Great Dmitry !
>
> We worked on something with Joe few months ago, mainly adding a new
> ZendMM handler which binds jemalloc().
>
> Anyway, I'm gonna try your code and run it against several Symfony2
> applications.
> I come back to you end of week with some results ;-)
>
> Julien
>

--001a11c3818af0dc2d04eff0e952--