Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33867
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Date: Sat, 8 Dec 2007 11:04:40 -0800
Message-ID: <698DE66518E7CA45812BD18E807866CE0100C741@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] Garbage collector patch
Thread-Index: Acg5wKLGG1y/d9WlROGd9qdRrlmphwADFATg
References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> <D37F0F93-EA19-4178-BCEE-91A7C36A7650@prohost.org> <7d5a202f0712031900i386f8964s675da26cc93af3fe@mail.gmail.com> <47550FAB.30002@daylessday.org> <698DE66518E7CA45812BD18E807866CEF890ED@us-ex1.zend.net> <475578BE.40908@daylessday.org> <4755A797.1020905@lerdorf.com> <009001c836ae$4ba0add0$e2e20970$@mcnaught@synergy8.com> <4755B310.9070603@lerdorf.com> <4755B55A.1030708@zend.com> <4755B61A.2000803@lerdorf.com> <50921.98.193.37.55.1197080740.squirrel@www.l-i-e.com> <FB18DCDE-5A7A-4181-86C9-820F24E09AC5@prohost.org>
To: "Ilia Alshanetsky" <ilia@prohost.org>,
	<ceo@l-i-e.com>
Cc: "Rasmus Lerdorf" <rasmus@lerdorf.com>,
	"Stas Malyshev" <stas@zend.com>,
	<scott.mcnaught@synergy8.com>,
	"Antony Dovgal" <tony@daylessday.org>,
	"Cristian Rodriguez" <judas.iscariote@gmail.com>,
	<internals@lists.php.net>
Subject: RE: [PHP-DEV] Garbage collector patch
From: andi@zend.com ("Andi Gutmans")

Hi Ilia,

I suggest more people test the performance difference because as you can
see for us it was negligible. From my experience you see bigger
deviations just by moving kernels, compilers, and even small patches
which affect where in memory the code segments sit, etc...
Maybe some people here who have performance harnesses (I'm sure Yahoo!
has one) could test it too.

Andi

> -----Original Message-----
> From: Ilia Alshanetsky [mailto:ilia@prohost.org]
> Sent: Saturday, December 08, 2007 9:35 AM
> To: ceo@l-i-e.com
> Cc: Rasmus Lerdorf; Stas Malyshev; scott.mcnaught@synergy8.com;
'Antony
> Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Garbage collector patch
>=20
> Richard,
>=20
> zval is such a common PHP structure that in a scope of a single script
> (even a trivial one) you'd have thousands of them. Therefor even an
> extra 4 bytes matter, and for people with large application it would
> matter even more. I wish the patch was such that it had no impact on
> the people who don't need it, but the reality is that for anyone who
> does not need gc cycles, it'll be a performance (speed & memory)
> penalty. This is why I had intimately suggested making it a compile
> time, configuration option.
>=20
>=20
> On 7-Dec-07, at 9:25 PM, Richard Lynch wrote:
>=20
> > On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote:
> >> Stanislav Malyshev wrote:
> >>>> 1. Always compile it in but leave undocumented #ifdefs in place
> for
> >>>> performance freaks.  Those same performance freaks aren't going
to
> >>>> care
> >>>> about the binary compatibility issue since they are the same
> people
> >>>> who
> >>>> build all their own stuff.
> >>>
> >>> Note that breaking BC is not only about performance - one your
> build
> >>> is
> >>> not the same as mainstream PHP, you can't use any binary extension
> >>> which
> >>> would do anything non-performance-related - like interfacing some
> >>> external system/library, debugging, profiling, testing, security
> and
> >>> so on.
> >>> Any commercial module won't be available for the user of this
> >>> switch,
> >>> and all open-source modules one'd have to build by oneself, which
> >>> may be
> >>> serious maintenance issue. I know there are a bunch of companies
> >>> that
> >>> compile PHP with their own options but still use commercial
> modules,
> >>> including both performance and non-performance ones. They couldn't
> >>> use
> >>> this compile switch.
> >>
> >> Yes, I know what binary compatibility means.
> >
> > Call me crazy, but...
> >
> > Would it be possible to hard-code the bit that adds the 4 bytes to
> the
> > zval, but make the execution bit a flag so that binary compatibility
> > is always there, but the executable code that does the GC can come
or
> > go as needed?...
> >
> > Or am I just talking nonsense due to ignorance?
> >
> > --
> > Some people have a "gift" link here.
> > Know what I want?
> > I want you to buy a CD from some indie artist.
> > http://cdbaby.com/from/lynch
> > Yeah, I get a buck. So?
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>=20
> Ilia Alshanetsky
>=20
>=20
>=20