hi,
On Tue, Apr 10, 2012 at 9:24 AM, Flavius Aspra wrote:
> I also subscribe to the opinion of object persistency not being worth it. In
> an application server, you could probably achieve more by keeping the entire
> phar in RAM.
>
> Currently, you can also simulate that by putting the phar on
On Apr 10, 2012, at 12:24 AM, Flavius Aspra wrote:
> On 04/09/2012 10:30 PM, Luke Scott wrote:
>> Yeah it would be. He also mentioned something about preloading
>> framework classes.. Would like to hear his thoughts on that!
>
> I also subscribe to the opinion of object persistency not being wort
On 04/09/2012 10:30 PM, Luke Scott wrote:
Yeah it would be. He also mentioned something about preloading
framework classes.. Would like to hear his thoughts on that!
I also subscribe to the opinion of object persistency not being worth it. In an
application server, you could probably achieve m
Pierre,
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> Something I have been discussed in the past with a couple of persons
> is to have a mechanism to automatically instantiate objects on request
> start. That's not persistent objects but that could already boost a
> little it the base foot
On Apr 9, 2012, at 7:49 AM, Flavius Aspra wrote:
> On 04/07/2012 05:21 AM, Luke Scott wrote:
>> From what I've gathered thus far, it is impossible to do without copying the
>>
>> non-persistent memory into persistent memory, and then back again.
>
> Hi, glad to see you again StackOverflow user:-)
On 04/07/2012 05:21 AM, Luke Scott wrote:
From what I've gathered thus far, it is impossible to do without copying the
non-persistent memory into persistent memory, and then back again.
Hi, glad to see you again StackOverflow user:-)
I think I've shown you the route by that [1] project, and
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> On Sat, Apr 7, 2012 at 6:51 PM, Luke Scott wrote:
>
>> I think I understand what you're getting at. So to avoid fragmentation
>> you would have to have two independent memory spaces. Making non
>> persistent memory persistent would require copyin
On Sat, Apr 7, 2012 at 6:51 PM, Luke Scott wrote:
> I think I understand what you're getting at. So to avoid fragmentation
> you would have to have two independent memory spaces. Making non
> persistent memory persistent would require copying from one space to
> another. Is that correct?
Yes, th
On Apr 7, 2012, at 9:45 AM, Pierre Joye wrote:
> hi,
>
> On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott wrote:
>
>>> The expensive parts here are not the object creation on its own but to
>>> get the data they contain (external, calculation, etc.).
>>
>> With heavy objects, yes. But when you have hu
On Apr 6, 2012, at 10:41 PM, Stas Malyshev wrote:
> Hi!
>
>> How is memory tracked with emalloc? From my observations anything
>> created with emalloc, with or without a zval wrapper, is freed at the
>> end of the request. Things created with pemalloc, which seems to be a
>> wrapper of malloc, is
hi,
On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott wrote:
>> The expensive parts here are not the object creation on its own but to
>> get the data they contain (external, calculation, etc.).
>
> With heavy objects, yes. But when you have hundreds of objects? The
> unseralization process in no more
On Apr 7, 2012, at 5:22 AM, Pierre Joye wrote:
> hi,
>
> 2012/4/7 Luke Scott :
>
>> It would be ideal of you could initialize a bunch of objects once and
>> carry them over to the next request. No serialization, no copying. A
>> lot of framework objects would benefit from this.
>
> The expensive
hi,
2012/4/7 Luke Scott :
> It would be ideal of you could initialize a bunch of objects once and
> carry them over to the next request. No serialization, no copying. A
> lot of framework objects would benefit from this.
The expensive parts here are not the object creation on its own but to
get
Indeed phpdaemon.net appears to cover this ground, although your idea might
deliver higher performance.
Sent from my iPhone
On Apr 6, 2012, at 7:46 PM, Luke Scott wrote:
> I've spent the last few days pouring over the Zend engine source code. I
> think I have a basic understanding on the memor
Neat idea. I have considered writing persistent php servers that just accept
requests serially. Possibly you could write a fastcgi server in pure php. That
would still delegate most of the grunt work to apache.
Sent from my iPhone
On Apr 6, 2012, at 7:46 PM, Luke Scott wrote:
> I've spent the
On Apr 6, 2012, at 5:23 PM, "Johannes Schlüter" wrote:
> Hi,
>
> On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>>
>>
>> From what I've gathered thus far, it is impossible to do without
>> copying the non-persistent memory into persistent memory, and then
>> back again. I'm assuming this is
On Apr 6, 2012, at 5:16 PM, Stas Malyshev wrote:
Hi!
>From what I've gathered thus far, it is impossible to do without copying the
non-persistent memory into persistent memory, and then back again. I'm
assuming this is because all the memory associated with PHP variables use
emalloc, which p
Hi,
On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>
>
> From what I've gathered thus far, it is impossible to do without
> copying the non-persistent memory into persistent memory, and then
> back again. I'm assuming this is because all the memory associated
> with PHP variables use emall
Hi!
> From what I've gathered thus far, it is impossible to do without copying the
> non-persistent memory into persistent memory, and then back again. I'm
> assuming this is because all the memory associated with PHP variables use
> emalloc, which places it onto a stack that is disposed of at the
I've spent the last few days pouring over the Zend engine source code. I
think I have a basic understanding on the memory management. Likely what I
say may be incorrect, so I apologize in advance.
What I'm trying to do is write an extension to persist PHP variables past
the end of the request in t
20 matches
Mail list logo
