Everything

php

RE: Re: CLI in PHP6

php.internals

J. Allen Dove

20 years ago

Unset() != free() is the bummer in the CLI env. :-( Def could use that
to help shape the performance contour in a daemon env since the
"request" never ends unless you self-terminate. Even then it can be
tricky to get that lifetime right if your loads change, etc.

-- AD

Jani Taskinen

20 years ago

There was some mail about the memory handling some time ago on
this list..something about making it better in these cases..
Try search the archives for this. (I can't find it right now)

IIRC, there even was a patch..

--Jani

On Thu, 6 Oct 2005, J. Allen Dove wrote:

> Unset() != free() is the bummer in the CLI env. :-( Def could use that
> to help shape the performance contour in a daemon env since the
> "request" never ends unless you self-terminate. Even then it can be
> tricky to get that lifetime right if your loads change, etc.
>
> -- AD
>
>> "leak", which honestly surprised me. We even explicitly unset the vars
>> but that doesn't guarantee the GC kicks off for them near-time?
>>
>>     unset() != free(). The memory allocated is still freed during
>>     the request shutdown (where GC actually kicks in).
>>
>> As a total aside, and being a paranoid C++ guy, I would love a "free"
>> method that I could call that frees what I tell it to exactly when I
>> tell it to... :-)
>>
>>     I think someone requested this before but it was shut down for
>>     some reason..can't remember what it was again.
>
>

--
Give me your money at @ <http://pecl.php.net/wishlist.php/sniper>
Donating money may make me happier and friendlier for a limited period!
Death to all 4 letter abbreviations starting with P!

Ron Korving

20 years ago

That would be nice. If all memory, even the stuff allocated by functions, is
freed at the end of the request, I can see where the problem is. It would be
very useful if this memory really would be freed at the moment all
references to it disappear. This would be a lot better for the CLI
environment, but also for a web environment, if you ask me, because the
memory required for handling pages might just be reduced by a big
percentage. I guess the question is: would this be a big performance hit in
processing time? (and I fear the answer is too big a "yes", otherwise I
expect it would've already been implemented).

Ron


"Jani Taskinen" <sniper@iki.fi> schreef in bericht
news:Pine.LNX.4.61.0510062142470.27450@arfg.argcubovn.sv...

Cristiano Duarte

20 years ago

Ron Korving wrote:

> That would be nice. If all memory, even the stuff allocated by functions,
> is freed at the end of the request, I can see where the problem is. It
> would be very useful if this memory really would be freed at the moment
> all references to it disappear. This would be a lot better for the CLI
> environment, but also for a web environment, if you ask me, because the
> memory required for handling pages might just be reduced by a big
> percentage. I guess the question is: would this be a big performance hit
> in processing time? (and I fear the answer is too big a "yes", otherwise I
> expect it would've already been implemented).

I agree that we should have a better memory aproach when running in CLI
environment. I work with PHP since 2000 and I currently have a CLI indexing
script that can eat 1Gb of memory (about 1Mb every minute) easily. IMO, for
the sucess of the CLI environment, we should have a function call that
*really* frees the memory allocated so it never gets to the GC (it's never
executed anyway in the process).

My company is huge (240000 employees and 50000 temporaries/year) and I'm
advocating PHP as a multiple purpose language(not only a web page scripting
language) despite what our Java advocating group say. Someone may point out
that PHP may not be the correct tool for the job, but I really think we
should have one tool that can handle most of our problems. If there is no
other way left, and I have to make scripts in Java, Python, Perl, C++, etc
please tell me before they know about it (so I have time to give it up: I
really don't want to).

Cristiano Duarte