Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51315 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75846 invoked from network); 19 Jan 2011 07:08:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jan 2011 07:08:39 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.64 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 76.96.62.64 qmta07.westchester.pa.mail.comcast.net Received: from [76.96.62.64] ([76.96.62.64:48094] helo=qmta07.westchester.pa.mail.comcast.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/B9-18515-6FD863D4 for ; Wed, 19 Jan 2011 02:08:38 -0500 Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta07.westchester.pa.mail.comcast.net with comcast id xK7S1f0011swQuc57K8djv; Wed, 19 Jan 2011 07:08:37 +0000 Received: from earth.ufp ([98.220.236.211]) by omta15.westchester.pa.mail.comcast.net with comcast id xK8c1f00B4aLjBW3bK8c4M; Wed, 19 Jan 2011 07:08:36 +0000 Received: from localhost (localhost [127.0.0.1]) by earth.ufp (Postfix) with ESMTP id 589E6D7A66 for ; Wed, 19 Jan 2011 01:08:35 -0600 (CST) Received: from earth.ufp ([127.0.0.1]) by localhost (earth.ufp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bczFc8L94zDH for ; Wed, 19 Jan 2011 01:08:35 -0600 (CST) Received: from linux-nkec.site (unknown [192.168.42.1]) by earth.ufp (Postfix) with ESMTPSA id 43FACD7A59 for ; Wed, 19 Jan 2011 01:08:35 -0600 (CST) To: internals@lists.php.net Date: Wed, 19 Jan 2011 01:09:52 -0600 User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.7-desktop; KDE/4.4.4; x86_64; ; ) References: <201101190045.31781.larry@garfieldtech.com> <4D368C58.2040903@yahoo.com.au> In-Reply-To: <4D368C58.2040903@yahoo.com.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <201101190109.52250.larry@garfieldtech.com> Subject: Re: [PHP-DEV] How deep is copy on write? From: larry@garfieldtech.com (Larry Garfield) That's what I was afraid of. So it does copy the entire array. Crap. :-) Am I correct that each level in the array represents its own ZVal, with the additional memory overhead a ZVal has (however many bytes that is)? That is, the array below would have $a, foo, bar, baz, bob, narf, poink, poink/narf = 8 ZVals? (That seems logical to me because each its its own variable that just happens to be an array, but I want to be sure.) --Larry Garfield On Wednesday, January 19, 2011 1:01:44 am Ben Schmidt wrote: > It does the whole of $b. It has to, because when you change 'baz', a > reference in 'bar' needs to change to point to the newly copied 'baz', so > 'bar' is written...and likewise 'foo' is written. > > Ben. > > On 19/01/11 5:45 PM, Larry Garfield wrote: > > Hi folks. I have a question about the PHP runtime that I hope is > > appropriate for this list. (If not, please thwap me gently; I bruise > > easily.) > > > > I know PHP does copy-on-write. However, how "deeply" does it copy when > > dealing with nested arrays? > > > > This is probably easiest to explain with an example... > > > > $a['foo']['bar']['baz'] = 1; > > $a['foo']['bar']['bob'] = 1; > > $a['foo']['bar']['narf'] = 1; > > $a['foo']['poink']['narf'] = 1; > > > > function test($b) { > > > > // Assume each of the following lines in isolation... > > > > // Does this copy just the one variable baz, or the full array? > > $b['foo']['bar']['baz'] = 2; > > > > // Does this copy $b, or just $b['foo']['poink']? > > $b['foo']['poink']['stuff'] = 3; > > > > return $b; > > > > } > > > > // I know this is wasteful; I'm trying to figure out just how wasteful. > > $a = test($a); > > > > test() in this case should take $b by reference, but I'm trying to > > determine how much of a difference it is. (In practice my use case has > > a vastly larger array, so any inefficiencies are multiplied.) > > > > --Larry Garfield