Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79576
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
Message-ID: <5489E693.1040605@mabe.berlin>
Date: Thu, 11 Dec 2014 19:46:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Stanislav Malyshev <smalyshev@gmail.com>, 
 Sara Golemon <pollita@php.net>
CC: PHP internals <internals@lists.php.net>
References: <54874642.6080508@mabe.berlin> <CAESVnVrSp-wfaKSD=MawGxUBPweFe3K8jHh6-H23ue7HbQ-hMA@mail.gmail.com> <54875152.3060808@mabe.berlin> <54880A15.50908@gmail.com>
In-Reply-To: <54880A15.50908@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] persistent zval
From: dev@mabe.berlin (Marc Bennewitz)


Am 10.12.2014 um 09:53 schrieb Stanislav Malyshev:
> Hi!
>
>> Why?
>>
>> There is a reference counter, which should be increased on put a value
>> into persistence and on removing a value from persistence decrease it.
>> So the GC could handle unreferenced zvals.
> Because memory which is allocated by the engine is freed at the end of
> the request. You could copy the memory values but by then unless your
> zvals are pretty simple you'll be pretty close to what the serializer
> does, so no really big win there. The only advantage would be that when
> you use it, if you're really careful, then you can use the data without
> reallocating memory and freeing it. But it's not just putting a
> flag/refcount on it, it requires some copying before that and some
> careful setting of the refcounts too. So in theory, it can be done at
> least for scalars and arrays (objects would be a problem since they need
> class, and what if the class changed?) but it's not trivial.
>
Thanks for the explanation!
I'll experiment with it for scalars as extension.

Marc