Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.169 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9AubPMqOE==002xrO2z4JksZQR1DxpBpc2MscjVB6eBg@mail.gmail.com>
References: <CA+9eiLtmUgWSZhoHgXy+UfiakGHG5RuJwP6o4txVsU76fRsDpQ@mail.gmail.com>
	<CAF+90c9AubPMqOE==002xrO2z4JksZQR1DxpBpc2MscjVB6eBg@mail.gmail.com>
Date: Mon, 20 Jan 2014 10:41:57 +0400
Message-ID: <CA+9eiLuVpSed_wHVCidExrFJY7f7spwJpfJ7dfa3eWyCoMxBFw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0444e98329020804f061308e
Subject: Re: New Memory Manager
From: dmitry@zend.com (Dmitry Stogov)

--f46d0444e98329020804f061308e
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

12% improvement on real task looks amazing :)
Was it on 32-bit or 64-bit PHP?

Thanks. Dmitry.



On Sun, Jan 19, 2014 at 2:05 AM, Nikita Popov <nikita.ppv@gmail.com> 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%
>>
>>
>>
>>
>>
>>
>>
>>  *PHP-5.6 64-bit* zend_alloc xx_malloc Improvement  blog 99.0 102.3 3.33%  drupal
>> 1531.1 1604.2 4.78%  fw 197.6 206.5 4.50%  hello 11702.0 11875.2 1.48%  qdig
>> 451.1 476.8 5.70%  typo3 541.8 568.7 4.96%  wordpress 176.5 185.8 5.27%  xoops
>> 126.1 134.5 6.66%  scrum 169.3 174.9 3.31%  ZF1 Hello 1042.9 1119.6 7.35%  ZF2
>> Test 238.4 242.5 1.72%
>>
>
> I tested your patch on some parsing code (which is very heavy on object
> creation for syntax trees) and saw ~12% performance improvement and ~15%
> memory usage improvement there. So looks like the new allocator works
> particularly well if a lot of object allocation is involved.
>
> Nikita
>

--f46d0444e98329020804f061308e--