Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Guilherme Blanco <guilhermeblanco@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Pierrick Charron <pierrick@php.net>, 
 guilhermeblanco@hotmail.com, Zeev Suraski <zeev@zend.com>, PHP Internals
 <internals@lists.php.net>
In-Reply-To: <AANLkTim-dHYyJxX2R3-PBVqqa3sv3+zKYr7zw7QvyngJ@mail.gmail.com>
References: <AANLkTimuWDV=9AA63_9M6cQSp9riCPE214sUNdoV3tQn@mail.gmail.com>
	 <4C873C0F.1010200@zend.com>
	 <AANLkTimdCnW3ABq5QSnBa78H14e2LPBa=Kt2txU0sTD4@mail.gmail.com>
	 <4C879613.7090709@zend.com>
	 <AANLkTim-dHYyJxX2R3-PBVqqa3sv3+zKYr7zw7QvyngJ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 08 Sep 2010 19:29:09 +0200
Message-ID: <1283966949.2118.146.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Wed, 2010-09-08 at 13:44 -0300, Guilherme Blanco wrote:
> >>> 2) I suppose that usage of annotation would be quite rare case. I don't
> >>> think it make sense to extend each op_array, property and class with
> >>> additional "annotations" field. I think it's possible to have a separate
> >>> CG(annotaions_map) where the keys might be the addresses of corresponding
> >>> classesm, methods and properties.
> >>
> >> Annotations are metadata related to a code element. IMHO it make sense
> >> to add them in the appropriate code element structures (even
> >> doc_comment is in those structures) so that APC and other cache will
> >> know that this is something part of the code element and it needs to
> >> be cached and so on.
> >
> > It's easier to keep it in appropriate places, but it's a waste of memory,
> > because only a few classes will use it. According to doc comments, in case
> > we accept annotations, I would represent it as a special kind of annotation.
> >
> > Separate map(enity -> anotations) would require memory only for defined
> > annotations. Of course it would be a bit more expensive to read it and would
> > require special handling in opcode hashes.
> 
> Argument is not reasonable IMHO.
> You may know that most code around web lack of documentation,
> specially docblock, so why not separate the docblocks on a separate
> structure too?
> Sorry, but your argument is not reasonable.
> Each class/property/method should contain all relevant information it
> can get, whatever it needs (docblock, annotations, visibility
> information, etc). Of course you have a bit of memory overhead, but
> it's a pointer, isn't it? So at the end, we will only have overhead
> when we have annotations defined.
> Also, decomposing the annotation definition and storage adds a level
> of dependency and indirection that may get things harder to comprehend
> by newer contributors.

Let's do some math:

A pointer on a 64bit architecture is 8 bytes. A random PHP binary of
mine has 1226 functions. And 133 classes. Each of them has, let's say 10
methods (i guess average is higher, but well).

Then I'm running an application, which has maybe 100 classes with 10
methods each.

This gives 8 * (1226 + 133 + 100 + (133 * 10) + (100 * 10)) bytes =
30.31 kilobytes.

Now I have 100 server children, so this are 3.021 megabytes on the
server.

Oh and that's only for the pointer which _could_ point to annotations
but will most likely point to NULL.

With the approach proposed by Dmitry this memory won't be used but
whenever annotations are accessed a lookup more will be needed.

This calculation is of course completely wrong to many wild guesses and
simplifications in there.

Of course that's not much but your statement shows what will happen
next:

    "specially docblock, so why not separate the docblocks"

First of all I claim that there are more docblocks than annotations.

Secondly what about the next pointer, and the next and the next somebody
wants to add, not only in the op array but other global structures, one
pointer in the zval, one in the hash bucket, one ...?

We can still move this over later when annotations are adopted and the
equation memory vs. CPU for this feature is valued differently.

johannes