Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51334
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.62.80 cause and error)
To: internals@lists.php.net
Date: Wed, 19 Jan 2011 20:17:28 -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> <4D3735F3.7020502@garfieldtech.com> <4D37697A.3090900@yahoo.com.au>
In-Reply-To: <4D37697A.3090900@yahoo.com.au>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <201101192017.28481.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] How deep is copy on write?
From: larry@garfieldtech.com (Larry Garfield)

On Wednesday, January 19, 2011 4:45:14 pm Ben Schmidt wrote:

> > Related: What is the overhead of a ZVal? I'm assuming it's a fixed
> > number of bytes.
> 
> It seems not, though a zval has a fixed size. What that size is will
> depend on the compiler and architecture of the system being used, or at
> least on the ABI.

Ah, yes, of course.  Oh C...

*snip*

> The zvalue_value union will probably be 8 or 12 bytes, depending on the
> architecture. The whole struct will then probably be between 14 and 24
> bytes, depending on the architecture and structure alignment and so on.

*snip*

> You can figure out what you think the overhead is from that. For a
> string, arguably the whole structure is overhead, since the string is
> stored elsewhere via pointer. Likewise for objects. For a double, the
> payload is 8 bytes, and stored in the zval, so there's less overhead. An
> integer, with a payload of 4 bytes, is somewhere in between.

Hm.  OK, so if I'm assuming a 64-bit architecture (most servers these days, 
I'd think) and just looking for a rough approximation, it sounds like 20 bytes 
per zval/variable is a not unreasonable estimation.  At least close enough for 
determining the memory overhead of a general algorithm.

Thanks again!

--Larry Garfield