Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80042
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <002a01d02522$469637f0$d3c2a7d0$@tekwire.net>
References: <CA+9eiLsT72Cihvn7xYyQHLsD1vHO9Ef1yXyJQ=iOi=7WO9XZ5Q@mail.gmail.com>
	<002a01d02522$469637f0$d3c2a7d0$@tekwire.net>
Date: Thu, 1 Jan 2015 16:46:55 +0400
Message-ID: <CA+9eiLuxanvm0PZkqs43a9381dEMWc3h_udVQH-78+mXtnPG0g@mail.gmail.com>
To: francois@tekwire.net
Cc: PHP Internals <internals@lists.php.net>, Xinchen Hui <xinchen.h@zend.com>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a11333a4c84fd76050b969e55
Subject: RE: [PHP-DEV] Merge HashTable and zend_array into a single data structure.
From: dmitry@zend.com (Dmitry Stogov)

--001a11333a4c84fd76050b969e55
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Fran=C3=A7ois,

this is not a proposal yet, this is just an initial request to the most
experinced PHP developers to think about possible consequnces.

Thanks. Dmitry.
On Dec 31, 2014 9:50 PM, "Fran=C3=A7ois Laupretre" <francois@tekwire.net> w=
rote:

> > De : Dmitry Stogov [mailto:dmitry@zend.com]
>
> > Please take a look into the patch
> >
> > https://github.com/php/php-src/pull/970/files
> >
> > This real changes are in zend_types.h, the rest is renaming that in mos=
t
> > cases makes code cleaner.
> >
> > zend_array didn't change its binary representation, but now it's not
> > possible to get a pointer to embedded HashTable. The same zend_array
> > shoukd
> > be used instead.
> >
> > Each HashTable got an extra 64-bit zend_refcounted header. This leads t=
o
> > some increase in memory consumption.
> >
> > The performance is slightly increased (may be measured with callgrind).
> >
> > The patch beaks one test (tests/lang/foreachLoopObjects.006.phpt), but
> > actually it just disclose a problem that we have anyway.
> >
> > The patch should be a base for the future optimizations. e.g. removing
> > HashTable->arData and/or HashTable->arHash and allocating them together
> > with zend_array; introducing EG(empty_array) etc.
>
> "Showing 46 changed files with 193 additions and 204 deletions". I am
> sorry but I can't analyze the impacts of your change, just from the patch=
.
> Did you write an RFC that would explain the impact, especially for
> extension writers ?
>
> More generally, what is the rule ? Is there a list of people who can
> introduce changes in the code, and even BC breaks in the C API, without
> writing RFCs, or is it just a question of rights/karma on the source
> repository ? I say that because it is especially hard to have a proposed
> change accepted on the mailing list, as several 'watchdogs' are there to
> dismiss ideas coming from people they don't know.
>
>

--001a11333a4c84fd76050b969e55--