Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara wrote: > Pierre et al, > > I would prefer to have it in pecl and merge once ready/cleaned up. > > Yes, same idea than with APC, except that it could be faster (for what > > I read, waiting to see the sources). Also we can review and do the > > changes more easily. > > > Well, I think the one issue with doing it in PECL first is that it prevents > some deeper engine integration that could benefit the implementation > significantly. > > With that said, I think it's a bit too tight to try to merge this in for > the 5.5 beta freeze. Given the current RFC process requires a minimum of 2 > weeks (1 of comments and 1 of voting), it feels tight. I'm not saying that > I think we should stick to the numbers hard in this particular case, but > it's also not a trivial patch, and I feel that rushing wouldn't be the > best idea. > > So with that said, may I suggest that we add 1 more round of Alpha to the > 5.5 release cycle, with the specific intent of merging this in (assuming > the implementation goes well). So we'd be talking about adding > approximately 2 weeks to the cycle, but it would ease the time and > implementation pressures that could otherwise cause issues. I think this > feature is worth pushing 5.5 back slightly, but at the same time not > delaying it indefinitely until this gets in. So if in 4 weeks (the time > until the beta, under this strategy) this isn't ready, it wouldn't make > 5.5. But at the same time it gives us enough time to implement it, > understand the implementation and make a decision that's based on a > concrete implementation than an "in-progress" one. > > Thoughts? > I'm ok with that, that's safe and clean :) Julien.P
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Fri, Jan 25, 2013 at 8:05 PM, Pierre Joye wrote: > On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf > wrote: > > On 01/25/2013 10:49 AM, Zeev Suraski wrote: > > > >> Ok, I'll write up an RFC, and in parallel we'll try to figure out the > >> mechanics of actually making it happen. > > > > Commit to master maybe and we can work on cleaning it up for the 5.5 > branch. > > I would prefer to have it in pecl and merge once ready/cleaned up. > Yes, same idea than with APC, except that it could be faster (for what > I read, waiting to see the sources). Also we can review and do the > changes more easily. > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I think I can help on things as well. I'm really looking forward in seeing the source code. I guess it will be PHP licenced right ? Julien.Pauli
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch wrote: > > On Jan 25, 2013, at 11:25 AM, Zeev Suraski wrote: > > >> Either by a number of people stepping up to help with the existing APC > > code, or > >> perhaps more realistically making it a priority in PHP 5.6 to streamline > > the > >> engine and the executor for opcode caching and either including a > > heavily > >> simplified version of APC or writing a new one. > >> > >> One thing I can guarantee is that if we add it to core in its current > > condition it > >> will delay 5.5 by 6+ months if not longer. > > > > There's another option. We have the Optimizer+ component which is > > current, a bit faster than APC, worked with PHP 5.4 from the get go and > > already fully supports 5.5 - and now that it's been free for use for > > several years, we'd actually be happy to opensource it and make it a part > > of core. An extra benefit would be that we'd commit to maintain it, > > although of course, community contribution will be very welcome. > > Here too, it's code with a very long history, some of which even predates > > PHP 4.0. But It Works(tm), and we could put some effort into cleaning it > > up and beautifying it. > > I like the idea. If this was implemented in core, and the need for APC > opcode caching disappeared, would APC still be actively maintained for > userland functions (e.g. apc_store, apc_*)? > Well, the APC idea was anyway to merge an Opcode cache to Core, and only an Opcode cache (correct if I'm wrong). apc_store() etc... are userland shared memory function, and should be migrated into another extensions, on which we could then allocate devs to work on, new ideas, etc... Julien.Pauli
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf wrote: > On 01/24/2013 11:56 PM, Ralf Lang wrote: > >> From what I understood from Rasmus the biggest challenge with merging > APC > >> into core is the fact that the compiler currently isn't built to support > >> opcode caching. One of the challenges he pointed out was some of the > >> MAKE_NOP trickery that can make APC's work a bit more complex than > >> necessary. It's possible to optimize the compiler enough to the point > that > >> APC's code could be reduced down to very simple opcode caching, putting > >> less stress on the engine and making it easier to maintain. > > > > I think there was some support for moving APC first from pecl to the PHP > > standard distribution's ext folder before any tighter integration is > > started. > > I'm really not convinced that by moving it to core we will magically get > people to help with it. I have been trying to get people interested for > years, and it hasn't gotten very far. Everyone wants it in the core, but > with a couple of exceptions, nobody is willing to actually work on it to > get it there. > > And I can understand the lack of help. It is probably the most > complicated piece of the entire stack. It is a an op_array juggler doing > a complex dance on a tight rope backwards and blindfolded. It is > essentially multi-threaded in that there are multiple processes all > reading and writing the same chunk of memory while dealing with a > compiler that spits out context-sensitive op_arrays that were never > designed to be cached and executed this way. > > So the learning curve is steep and the bugs are extremely hard to track > down because it is the only PHP component that isn't a perfect sandbox. > A slight memory corruption almost anywhere in any extension can segfault > a dozen requests later with a backtrace that points to the opcode cache > code. Not to mention web servers like Apache that longjmp() on us at the > wrong time. Zend-signals addresses this, but even in 5.4 they aren't > enabled by default because of stability issues and without those no > shared memory opcode cache is safe. > > I firmly believe that we need opcode caching in core. I'm rather > skeptical that simply moving pecl/apc to ext/apc is going to help users > in any way. People have no trouble finding and installing APC today. The > real issue here is robustness and lag time between a PHP release and and > solid APC release and that has to do with resources which are scarce due > to the code complexity. This is the real problem we need to solve. > Either by a number of people stepping up to help with the existing APC > code, or perhaps more realistically making it a priority in PHP 5.6 to > streamline the engine and the executor for opcode caching and either > including a heavily simplified version of APC or writing a new one. > That feels like a safe idea. I'm convinced that having more internals documentation will help developpers understand at least the engine (that's what interest us here). I know it's a hard task, but we all here have blogs where sometimes we write great articles about a part of internals, I think we should focus on working alltogether writing a real technical doc for the engine, that will help people (like me for example), understand some dark parts of it, and then find ideas or solutions for it to evolve the right way. > One thing I can guarantee is that if we add it to core in its current > condition it will delay 5.5 by 6+ months if not longer. > Ok that seems clear. Julien.Pauli
[PHP-DEV] PHP5.5.0alpha4 is ready for testing
Hi Internals, PHP 5.5.0alpha4 has been tagged today. This release contains bug fixes against alpha3, and adds the class name resolution via scalar and the DateTimeImmutable The packages can be found at: http://downloads.php.net/dsp As you know, you may read the NEWS file in the source tree for full changelog of this release. Please test PHP5.5.0alpha4 carefully, and report any bugs in the bug system. We may begin now the beta stage of 5.5.0. Please, be warned that now features are frozen, betas won't accept new features to be added and should focus on consolidate the code against bugs. The first beta should be tagged on February 7th. We would like to thank all the contributors that made this alpha4 possible. Regards David and Julien
[PHP-DEV] PHP5.5.0alpha3 released
Hi Internals, PHP 5.5.0alpha3 has been tagged today. This release contains bug fixes against alpha2, as well as new features in existent APIs. The packages can be found at: http://downloads.php.net/dsp As you know, you may read the NEWS file in the source tree for full changelog of this release. Please test PHP5.5.0alpha3 carefully, and report any bugs in the bug system. Alpha 4 will be tagged on January 24th. Thank you all contributors who pushed code and ideas for this alpha3. Regards David and Julien
Re: [PHP-DEV] Re: Was Reflection annotations reader - Pull APC in Core Already
On Wed, Jan 9, 2013 at 6:06 PM, Derick Rethans wrote: > On Wed, 9 Jan 2013, Anthony Ferrara wrote: > > > Rasmus wrote: > > > > > This is my worry as well. Especially when it comes to opcode cache > > > support. Most of the patches I see these days completely ignore the > > > opcode cache side of things which needs to change. For any large > > > language-level change, any implementation that doesn't also include > > > an APC diff, or at least a very complete explanation of how it will > > > be generally supported by opcode caches just isn't complete. > > > > > So I guess my point is rather than passing the message that people > > making language changes need to think about APC, I think the message > > should be that APC needs to get into core (and should be made an > > initiative)... As it stands now, it's just going to keep causing > > pain... > > It was a plan in the past, I think we should just do it - now. > I fully 100% agree with that. Reading Rasmus 5min ago on the other topic (annotations) made me think about writing such a topic again. But Anthony's been faster ;-) Rasmus, Anthony's arguments make full sense : if any Core feature addition need to be thought so that APC need to be patched correctly, then we have to move APC to Core. Not having at least one default Opcode cache solution in Core, even disabled by default in runtime configuration really is a nonsense. And I guess this will solve the "PHP5.4 adoption problem" as well, you see what I mean, so we won't meet it again in the future. That's been very bad for 5.4 adoption, and for PHP itself though. kindly, Julien.Pauli
Re: [PHP-DEV] PHP5.5.0alpha2 release
On Fri, Dec 21, 2012 at 1:51 AM, Adam Harvey wrote: > On 21 December 2012 01:26, jpauli wrote: > > We just tagged PHP 5.5.0alpha2 today. This > > release contains bug fixes against alpha1, as well as > > new features. > > Are we going to have a news post for this on the Web site? > (Alternative question: would you like me to write one?) > Yep, writing it for today :-) Julien
Re: [PHP-DEV] PHP5.5.0alpha2 release
On Thu, Dec 20, 2012 at 9:30 PM, Hannes Magnusson < hannes.magnus...@gmail.com> wrote: > From: jpauli > Date: Thu, Dec 20, 2012 at 9:26 AM > Subject: [PHP-DEV] PHP5.5.0alpha2 release > To: PHP Internals > > > > I would appreciate that you would use your full real name now that you > are representing the project as a release manager > > > Ok I will. Julien
Re: [PHP-DEV] deprecating ext/mysql
I agree with Johannes and Oracle/MySQL people : ext/mysqli must be the preferred way to replace ext/mysql. PDO lacks advanced features which wont be available because of PDO internals incompatibility. ext/mysqli is a true MySQL internal API exposure into PHP user land, PDO is not. Moreover, ext/mysqli has a userland API that is really the same as ext/mysql one; it's been a design rule of ext/mysqli to ease a future migration. PDO is really different and needs objects, not every single PHP developper is ready to use object nowadays. Julien.P 2011/7/16 Philip Olson : > Hola friends, > > Nice feedback so far, and the PHP documentation will begin implementing > the ideas presented here, and focus on mysqli but also recommend pdo_mysql. > Therefore, the ext/mysql documentation will be improved to strongly > recommend the preferred alternatives that have existed since PHP 5.0.0. > > We'll work on the finer details but it feels like procedural mysqli is a > better fit to live alongside the ext/mysql examples, although we don't want > to confuse people. Maybe geeks here have ideas regarding this, but a clear > useful clutter-free solution will be worked out, which may include adjusting > the CSS and involve creative linking. I'll add an example or three soonish. > > However, there has been some confusion within the PHP community, so to help > ease these concerns: > > - This proposal only deals with documentation/education... so it can be > described as an official 'soft deprecation' (no errors or code changes) > - When (if?) this extension emits errors, or is removed, is not part of > this proposal > - There is a 100% chance that additional tasks and ideas will be discussed > in the future, which might include: > - A conversion tool/guide > - A wrapper > - A PECL extension > - Talking to distros/hosters and apps like wordpress > - ... > - php.net understands that ext/mysql is popular, and we're handling this > with extra care and heck, parts of *.php.net is powered by ext/mysql > - Seriously, no need to panic > > We'll document the reasons why the other MySQL extensions are preferred, but > if people want to use the old ext/mysql API with PHP 9.0.0 (just an example) > then I'm guessing an old geek out there will make that possible. We, however, > will do our best to convince users to move towards the preferred and > supported methods, and hopefully write better code along the way because > honestly, that's the ultimate goal here. > > Regards, > Philip > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] set_http_response_code() to PHP5.4 ?
Hey,
I've seen Kalle's patch for http://bugs.php.net/bug.php?id=52555.
It actually implements a http_response_code() function to export the
current HTTP response code from SAPI layer to PHP user land.
I'm suggesting to rename that function to get_http_response_code(),
and implement its sister : set_http_response_code().
Something like that should make it :
PHP_FUNCTION(set_http_response_code)
{
long code;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &code) ==
FAILURE)
return;
sapi_header_op(SAPI_HEADER_SET_STATUS, &code TSRMLS_CC);
RETURN_TRUE;
}
That would help changing the http response code.
Actually, that can only be done in weird ways, like
Julien
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trying to find out where the memory went
I wrote about ZendMM some time ago (http://julien-pauli.developpez.com/tutoriels/php/internals/zend-memory-manager/) , that's in french language ;-) To shorten the conversation a little bit, I would suggest to trace the memory with valgrind/massif. That's not too hard if you know what you do, if not, then it can take some time. Basically, Johannes gave some good hints; but memory management is a hard task to compute and deal with, I suggest you dont try to figure out how many memory it "would" take, as the computation is really too hard to be accurate. Only memory debuggers will show you exactly what happens. BTW, there might be a little leak inside token_get_all() as it doesn't seem to free memory it allocated. Not very easy to find as it plays with lex scanner. Julien.P 2011/6/8 Johannes Schlüter : > On Tue, 2011-06-07 at 21:03 +0200, David Zülke wrote: >> 144 (not 114!) bytes is for an integer; I'm not quite sure what the >> overheads are for arrays, which token_get_all() produces in >> abundance :) An empty array seems to occupy 312 bytes of memory. >> >> Also, strings have memory allocated in 8 byte increments as far as I >> know, so "1" eats up 8 bytes, and "12345678901234567" will consume 24 >> bytes for the raw text, not 17. > > I'm too lazy to do the actual math (well best would be to do > sizeof(zval), sizeof(HashTable), sizeof(Bucket) on your system) and > there are few things to consider: > > * The sizes are different from 32 bit and 64bit; with 64bit > there's a difference between Windows and Unix/Linux (on Win a > long will still be 32 bit, but pointers 64 bit, on Linux/Unix > both are 64bit) > * On some architectures memory segments have to be aligned in some > way which might waste memory > * As David mentioned HashTables (Arrays) are more complex. > * token_get_all() returns an array of (string | array of (long, > string, long) ) > * A long takes sizeof(zval) > * A string takes sizeof(zval)+strlen()+1 > * and array is a HashTable + space for buckets, this includes > place for some not used elements > * Each element inside the HT needs additional space for a Bucket > with some meta data > * While running your script you also keep the complete script file > in memory. You also keep some temporary parser data in memory > while the resulting array is being filled. > > In the end it's not fully trivial to gather the size needed. And I'm > sure my list is missing lts of things. > > http://schlueters.de/blog/archives/142-HashTables.html has an short > introduction to HashTables. Skipping many of the details. > > johannes > >> David >> >> >> On 07.06.2011, at 20:26, Mike van Riel wrote: >> >> > Am i then also correct to assume that the output of >> > memory_get_peak_usage is used for determining the memory_limit? >> > >> > Also: after correcting with your new information (zval = 114 bytes >> > instead of 68) I still have a rather large offset: >> > >> > 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = >> > 125M >> > >> > (not trying to be picky here; I just don't understand) >> > >> > _If_ my calculations are correct then a zval should be approx 216 bytes >> > (excluding string contents): >> > >> > ((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B >> > >> > Mike >> > >> > On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: >> >> memory_get_peak_usage() is the maximum amount of memory used by the VM of >> >> PHP (but not by some extensions for instance) up until the point where >> >> that function is called. So the actual memory usage may be even higher >> >> IIRC. But yeah, you're basically right. I've explained in another message >> >> why it might be so much more than you expected (zval overhead, basically) >> >> >> >> David >> > >> > >> > >> > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
+1 , nice job
Julien
On Mon, Jun 6, 2011 at 12:53 PM, David Zülke
wrote:
> <3
>
> David
>
>
> On 05.06.2011, at 17:52, Felipe Pena wrote:
>
>> Hi all,
>> Reading our bug tracker I noticed a good feature request [1] from 2009 which
>> points to an interesting feature that I think makes sense for us, since we
>> are now working with $f() using objects and strings, and the array('class',
>> 'method') is an old known for call_user_func()-like functions.
>>
>> So, I wrote a patch [2] that allow such behavior to be consistent with
>> arrays. See some examples:
>>
>> class Hello {
>> public function world($x) {
>> echo "Hello, $x\n"; return $this;
>> }
>> }
>>
>> $f = array('Hello','world');
>> var_dump($f('you'));
>>
>> $f = array(new Hello, 'foo');
>> $f();
>>
>> All such calls match with the call_user_func() behavior related to magic
>> methods, static & non-static methods.
>>
>> The array to be a valid callback should be a 2-element array, and it must be
>> for the first element object/string and for the second string only. (just
>> like our zend_is_callable() check and opcodes related to init call)
>>
>> Any thoughts?
>>
>> [1] - http://bugs.php.net/bug.php?id=47160
>> [2] - http://felipe.ath.cx/diff/fr47160.diff
>> phpt: http://felipe.ath.cx/diff/fr47160.phpt
>>
>> --
>> Regards,
>> Felipe Pena
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trying to find out where the memory went
Seems like leak.
Try disabling ZendMM to see if something noticeable happens (memory
peak should be lower).
USE_ZEND_ALLOC=0
Cheers,
Julien
On Sun, Jun 5, 2011 at 2:01 PM, David Zülke
wrote:
> Smells like a memory leak if gc_collect_cycles() doesn't fix it.
>
> David
>
>
> On 05.06.2011, at 00:01, Mike van Riel wrote:
>
>> Hey David,
>>
>> That gives me the following output:
>>
>> int(640720)
>> int(244001144)
>>
>> Mike
>>
>> On Sat, 2011-06-04 at 23:51 +0200, David Zülke wrote:
>>> What does
>>>
>>> var_dump(memory_get_peak_usage());
>>> token_get_all(file_get_contents(''));
>>> var_dump(memory_get_peak_usage());
>>>
>>> get you?
>>>
>>> David
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] INF behavior
Agree with Derick, strictly speaking, in maths science, INF != INF. But I dont care if PHP tells me than yes, because PHP is not designed to solve high level maths problems :) Cheer, Julien.Pauli On Fri, May 27, 2011 at 4:48 PM, Derick Rethans wrote: > On Thu, 26 May 2011, Scott MacVicar wrote: > >> On 26 May 2011, at 20:03, Philip Olson wrote: >> >> > Hello geeks, >> > >> > A geek is needed to clarify PHP bug #45712. This is an edge case but the >> > test (bug45712.phpt) contains code similar to the following: >> > >> > > > $inf = pow(0, -2); >> > >> > var_dump($inf); // float(INF) >> > var_dump($inf == $inf); // bool(false) >> > var_dump($inf === $inf); // bool(true) >> > ?> >> > >> > That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, >> > but PHP 5.4.0-dev changes behavior so both now return true. >> > >> > Is this is how we want it? And how should this be documented/explained? >> >> I think I changes this :-) >> >> It didn't make sense that == and === produce different results. >> >> Though if someone has a better understanding of maths then we can fix it. > > I think it does make sense. == is the equal operator, and INF is not > equal to INF (just like SQL NULL is not equal to NULL). However, they > are identical (like you can test in SQL with NULL IS NULL). > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Improved parser error message
I remember error messages have been improved since last decade, but they were engine ones. Parser ones have never been touched, so to improve them, I +1 your idea Felipe :) Julien On Mon, May 16, 2011 at 7:52 PM, Florian Anderiasch wrote: > On 16.05.2011 14:15, Felipe Pena wrote: >> Other examples and patch at: >> https://wiki.php.net/rfc/improved-parser-error-message > > Just for completeness, here's the lengthy thread > we had in October 2010 about this: > > http://news.php.net/php.internals/49978 > > FWIW, I like the Easter Egg :) > > Greetings, > Florian > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unmaintained SAPIs
All right ;-) Johannes: Thanks for details about lighhtpd's internals. Julien.P 2011/4/27 Johannes Schlüter > On Wed, 2011-04-27 at 15:36 +0200, Julien Pauli wrote: > > I'm +1 with that list. > > > > I'd like to have some time to work on a lighttpd sapi if possible > > (haven't seen lighttpd API yet). If someone got the same idea, just > > tell it... > > lighty's API for that is FastCGI. There is an native API, but plugging > in PHP there would be bad in regards to lighty's event-based > architecture. > > > What about apache2filter SAPI ? > > What what? I didn't here from people who are using or maintaining it ... > so it's on the "i don't know" list. > > johannes > > > Julien.P > > > > 2011/4/24 Pierre Joye > > 2011/4/24 Rasmus Lerdorf : > > > On 4/24/11 4:41 AM, Pierre Joye wrote: > > >> > > >> hi, > > >> > > >> Do we really need apache 1.x SAPIs? > > >> > > >> ISAPI should be kept in (was decided so by the 5.3.0 > > release time), it > > >> is still used and works for users with custom versions. A > > new version > > >> may come as well, as part of one of some features I'm > > working on. > > > > > > Your argument for ISAPI applies exactly to Apache 1 as well. > > > > > > Not that it is so important (does not hurt anyone to keep it > > in) but > > apache 1.x is dead, not IIS :). > > > > Cheers, > > -- > > Pierre > > > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > > > -- > > > > > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > >
Re: [PHP-DEV] Unmaintained SAPIs
I'm +1 with that list. I'd like to have some time to work on a lighttpd sapi if possible (haven't seen lighttpd API yet). If someone got the same idea, just tell it... What about apache2filter SAPI ? Julien.P 2011/4/24 Pierre Joye > 2011/4/24 Rasmus Lerdorf : > > On 4/24/11 4:41 AM, Pierre Joye wrote: > >> > >> hi, > >> > >> Do we really need apache 1.x SAPIs? > >> > >> ISAPI should be kept in (was decided so by the 5.3.0 release time), it > >> is still used and works for users with custom versions. A new version > >> may come as well, as part of one of some features I'm working on. > > > > Your argument for ISAPI applies exactly to Apache 1 as well. > > Not that it is so important (does not hurt anyone to keep it in) but > apache 1.x is dead, not IIS :). > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Re: Zend mm
You should take care not to mistake the GC and the MM, they are two different things and surprisingly, they dont interact with each other. Zend GC is a layer above Zend MM, and Zend GC can be totally disabled, Zend MM cant at all. Zend MM is a BIG layer over malloc()/free() which goals are mainly to abstract the OS MM (mainly Unix/Win32) and to avoid memory fragmentation and too many system calls which could lead to performance problems. Lots of other programms use such a tool, like Apache httpd for example. Zend MM can also help you (in debug mode only) by showing its state after a script has run, alowing you to easily track memory leaks while using it (e**() functions) without the need to use tools such as valgrind. ZendMM can track all the PHP memory usage, and provide feature such as "memory_limit". Finally, ZendMM is a super malloc(), it nearly can be foreseen as a custom implementation of libc malloc() using a heap over the heap and trying to optimize it as possible. Simply looking at the structs in zend_alloc.h let you guess it's goal, but you need to know how memory management works in computer programs for that. Julien.P On Wed, Feb 2, 2011 at 7:52 AM, Adi Mutu wrote: > > Thanks a lot, for all the help about zend mm guys, i'm very grateful. > Thanks,A. > > --- On Sun, 1/30/11, Ben Schmidt wrote: > > From: Ben Schmidt > Subject: Re: [PHP-DEV] Re: Zend mm > To: "Adi Mutu" > Cc: internals@lists.php.net, t...@daylessday.org > Date: Sunday, January 30, 2011, 4:45 PM > > On 30/01/11 4:11 AM, Adi Mutu wrote: >> I have looked at the sources, but i'm only at the begining of >> analyzing the php sources.i've understand how to write extensions >> for example, but this memory manager seems more complicated to me. > > Yes, it is. Memory management is a low-level and subtle area. It takes a > lot of careful thought to design and even to understand the algorithms > involved. It is hard to debug, because an error caused in one place may > not show itself until completely different code is executing. It is also > an area which doesn't change much. Almost all the other code in the PHP > interpreter, and therefore PHP scripts themselves, rely on the memory > manager code doing its job unintrusively and correctly, so once it is > working well, it tends to be left that way, except for fixing small bugs > as they are found, or a big and careful development effort to address > some limitation (e.g. improving the garbage collection to collect > cycles, which was something done fairly recently). > > The bottom line is that this is not an area that is all that easy for > beginners to get their teeth into. But it's also an area that isn't > necessary for beginners to understand in much detail, either. Unless you > have a particular project in mind that involves the memory manager, you > probably don't need to touch it. > > I don't want to discourage you, but just point out that perhaps this is > something you might look at later, or even not at all, as you may find > there are many worthwhile projects that take up all your time before you > ever get to understanding the memory manager fully. > >> It would be useful if for example, could explain me the structures >> that are used in the Zend memory manager, how they're chained >> etc.and if you can tell me in words what do zend_mm_aloc_int() and >> zend_mm_free_int() basically do...Thank you for your time,Adrian > > I suspect these structures and functions are fairly easy to understand > by someone familiar with the area of memory management, which is why you > have been advised to consult the source code. So perhaps what you need > to do is not learn about PHP's memory manager, but just learn about > memory management in general. Then it should be fairly easy to > understand what PHP's memory manager is doing from its code. > > I'm afraid I doubt the people here have the time to teach you this over > email. :-) So here are some references which might be of use to you. > > - I believe the 'standard textbook' for learning about memory management > is this one here: > http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html > > - This page also mentions that a new edition is due out soon: > http://c2.com/cgi/wiki?GarbageCollectionBook > > - You can also check out this site: http://www.memorymanagement.org/ > > - Relating this to, PHP: PHP is a garbage collected language which I > believe uses reference counting and a clever collector to detect and > free cycles. I haven't looked in detail into the implementation, but I > know some documentation is available on the subject here: > http://www.php.net/manual/en/features.gc.php > > Hope this helps! > > Ben. > > > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] implicit reference
Ow, what a crap idea ... You want to make the same php4-written source code run with PHP4 AND PHP5.3 ? That seems like an unsolvable challenge, I think that even if you dont mind very bad codes/stuff you won't make it fully work for production without alarms every minutes ... Good luck, Julien On Mon, Jan 31, 2011 at 9:10 PM, Pierre Joye wrote: > On Mon, Jan 31, 2011 at 9:08 PM, Mathias Grimm wrote: >> the constraint is that all need to run on php4.3.6 and 5.3 > > You may not have the choice but that's simply a very bad idea. > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
Well, I can't answer precisely about kernel fork() implementation and possible copy on write mechanisms. May vary across systems. Someone here could answer I suppose. 'top' on httpd process with a prefork mpm gives each child process memory as a whole XxxMb process, but I don't know what kind of memory top sees (and other tools such as 'free'). Anyway, even with a good kernel process COW, threaded systems tend to be less memory hungry than equivalent forked systems. APC uses shared segments with differents tools such as shm, mmap etc... (chosen at compile time). J.Pauli On Wed, Dec 15, 2010 at 12:58 PM, Jon Davey wrote: > 2010/12/15 Julien Pauli >> >> Well, I would say that if your problem is memory, you should consider >> threads as they all share the same memory space in their process. >> >> Apache's children can weight very heavy if PHP's been compiled to >> support lots of extensions, you can happen with ~40/50Mb per process >> which is very huge. Considerating 50 parallel processes eat up 2-3Gb >> for example. >> > > Surely creating a fork of a 50MB process will not consume an > additional 50MB because of copy-on-write virtual memory? I would think > you would only see this growth in memory usage if the extensions > maintained a large payload of data that was being heavily modified in > each request, such as caches, but I expect they create their own > shared memory segments (I have yet to check the source of APC). > > Jon > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Performance in Apache: Multi-Process vs Multi-Threaded
Well, I would say that if your problem is memory, you should consider threads as they all share the same memory space in their process. Apache's children can weight very heavy if PHP's been compiled to support lots of extensions, you can happen with ~40/50Mb per process which is very huge. Considerating 50 parallel processes eat up 2-3Gb for example. In threaded environment, the best thing you'll get is a lot of memory savings. The impact on CPU time is roughtly the same that with processes (Unix). Beware of non thread safe extensions/libs ; they'll cause you brain damage for sure. J.Pauli On Tue, Dec 14, 2010 at 8:22 PM, jvlad wrote: > "Israel Ekpo" wrote in message > news:aanlkti=ixwqkkovkyuluqckdvklqy2nyeyg6pjfza...@mail.gmail.com... >> In multi-process environments, such as FastCGI, Apache Prefork MPM etc, >> PHP >> needs to execute the MINIT and MSHUTDOWN functions for all loaded >> extensions >> on every request. > > You're not correct here. A process can handle quite a lot of requests and > MINIT/MSHUTDOWN is executed only once. > So the MINIT/MSHUTDOWN overhead is negletable. > >> It is also more expensive to create new processes than to create new >> threads. > > Correct, but it's rarely needed to create them in both cases. So expense of > creation plays almost no role. > What plays role is switching the context when some overlapping requests are > processed. With thread it's less expensive. > But still, switching is a huge overhead when you run a server with 1K or 10K > overlapping requests. > If you talk about 10 or 40 - there is almost no difference. > >> In one-on-one comparisons between scripts executed only once in ZTS mode >> and >> scripts executed once in non-ZTS mode, >> I noticed that the one in non-ZTS mode was slightly faster > > that's because in ZTS case all data is in thread-safe structures and there > is quite a big overhead accessing any field of the structures. > >> and this seems to >> be the main reason why most people go with the non-ZTS enabled setups. > > No. Php if we talk about php with all its extensions is not threadsafe at > all. Many of the extensions allocate static data and inherently > non-thread-safe. > >> But the reason for this slight difference in speed is because of the >> differences in the data structure for globals for ZTS and non-ZTS modes. > > correct. > >> Other reasons people have cited for going with non-threaded setups include >> stability which I guess we should not really be concerned about if >> non-threadsafe extensions are excluded. > > Correct. But you never know which one is truly threadsafe. > I'd only say that it's safer to use extensions that do not depend on 3rd > party libraries at all, or at least > depend on libraries written with threadsafety in mind. > >> Has anyone performed any load tests benchmarks comparing the two setups >> (Multi-Process vs Multi-Threaded)? > > Could you please shed some light on what load volume you're talking about? > 1, 10, 100, 1K, or10K of requests per second? > > with a regular web site which is handling ~4-5K visitors a day, you can > hardly get more than 10-15 requests per second. > In this case you may want to get what so ever php and apache distributed > with your OS and do not spend you time on anything else. > If you foresee 10K requests per second, it's better not to use PHP and > especially not to use Apache at all. > > -j > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
I don't remember the source, refresh my mind quickly please : What happens if variables_order doesn't content 'P' ? Is the data still duplicated into memory ? I know that $_POST is still there but is an empty array in that case. And yes, I'm +1 for such a patch :) J.Pauli On Tue, Dec 7, 2010 at 5:43 PM, Sergio A. Kessler wrote: > John Mertic php.net> writes: > > [snip] >> Wouldn't something like this work? >> >> >> php_value disable_post_data_processing On >> > > maybe it should be: > > php_value post_data_processing Off > > so you don't have double negation in the case of > > php_value disable_post_data_processing Off > > > regards, > /sak > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
I guess serialize mechanism cant use any char that can be part of a PHP variable. And "_" can. As property names respect binary compatibility, the only char that can be used to mark private properties is actually the NULL byte. Ping me if I'm wrong. But I'm +1 for improving the serialize() speed, I had problems recently with it, and igbinary came to save me as well :) Julien.Pauli On Sun, Nov 28, 2010 at 5:15 PM, Jonathan Bond-Caron wrote: > On Thu Nov 25 12:47 PM, Andi Gutmans wrote: >> >> I know there have been some high-end apps that have benefited from >> some custom serializers, etc... (typically platform dependent). >> I wonder if people here think improvements in these areas would move >> the needle for the majority of mainstream apps or not. >> > > Like people have mentioned, improving (un)serialize speed would be a huge > benefit, especially for caching data sets or large objects. > > From experience, it would seem valuable to have: > 1) serialize_text($var) > > The existing serialize() minus the NULL bytes on private properties. It has > been a source problems for developers serializing an object with private > properties and storing it in a database (the string may get cutoff). > > I'm not sure why there's a NULL byte in 'zend_mangle_property_name', instead > the char "_" could be used to mark a private property in the serialized > text. > The unserialize could be BC compatible accepting both NULL and "_" around a > private property. > > 2) serialize_binary($var) > > An efficient and compact serialization using techniques from igbinary. > > A potential problem with igbinary I've noticed is it packs a double as a 64 > bit integer. > That could be a problem if you serialize on a platform that has an IEEE 754 > binary representation and unserialize on a non-IEEE platform but I don't > know if php compiles on architectures that are non-IEEE. > > It could also be interesting to pack integers as varints: > http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints > http://protobuf-c.googlecode.com/svn/trunk/src/google/protobuf-c/protobuf-c. > c > > That's most likely slower though then what igbinary does with integers > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] new foo()->bar()
Care should be taken in the case of new myClass()->foo() just creates an object to call a method but a static method would be more efficient here. However, well used (fluent interface for exemple) make me think +1 for that patch. J.Pauli On Mon, Nov 29, 2010 at 12:40 PM, Felipe Pena wrote: > Hi Dmitry, > > 2010/11/29 Dmitry Stogov > >> Hi Felipe, > > >> I'm wondered it works out of the box with so small patches :) >> >> However, both patches introduce new parser conflicts and it would be grate >> to avoid them. >> >> > I will check if there is any way to avoid it. > > >> Also the patches need to be checked for memory leaks in case of exceptions >> thrown from constructor and chained function(s). >> > > Yes, I already did several tests to check this. > > >> It also probably makes sense to add array deference chaining e.g. new >> Foo()[] (just for language consistency). >> >> > Hmm, looks good to me. :) > > > Thanks. > > -- > Regards, > Felipe Pena > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding path_len to all stream functions in trunk
Is this related to http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/ ? That's a quiet old bug, I'm happy to listen it's now worked on and has a patch. J.Pauli On Tue, Nov 16, 2010 at 12:34 PM, Pierre Joye wrote: > hi, > > On Tue, Nov 16, 2010 at 7:15 AM, Rasmus Lerdorf wrote: >> On 11/15/10 10:12 PM, Stas Malyshev wrote: >>> Hi! >>> Well, it changes the signature of that function, so while we don't break backward binary compatibility, we break forward compatibility within the 5.3 branch. As in, if I change my extension to use this new NoNull string flag, it will no longer work on<5.3.3 whereas if I do the if(strlen(filename) != filename_len) check, this will still work in all 5.3 releases. >>> >>> So if you have such extension, and you need to have it compatible with >>> previous versions (e.g. PECL one), use the check. That doesn't prevent >>> us from having the flag in the core code and thus keeping it cleaner. >> >> It still worries me a bit. Distros love to separate core extensions >> into separate packages and if you update one of those without updating >> the core package, it will break. Hopefully they have hard dependencies >> so you can't install php-curl-5.3.4 on php-5.3.3, for example. > > Same here, it is somehow a API incompatibility. We did similar changes > in the past and forced us to have two versions of extensions (afair it > was <5.2.5 and >=5.2.6). That was really painful and took years to get > rid of 5.2.5 support. > > I like the idea of having a (maybe not so perfect) solution for 5.3.x > using Rasmus patch and do it right in trunk. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Well at least I fixed the splweaktypehintingwithautoboxing for the function to return ++$var instead of $var++ which couldn't make it ;-) Julien On Mon, May 31, 2010 at 5:54 PM, Ferenc Kovacs wrote: > On Mon, May 31, 2010 at 2:42 PM, Lukas Kahwe Smith >wrote: > > > > > On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote: > > > > > > > > On 28.05.2010, at 11:22, Etienne Kneuss wrote: > > > > > >> so, it would be nice to update the RFC(s), so that we have a solid > > >> ground on which we can discuss/vote. > > > > > > > > > i agree. i currently see 5 fundamental different options on the table: > > > > > > 1) current trunk > > > 2) current trunk but only with scalar/numeric type support > > > 3) weak typing with current PHP conversion rules that raise an E_STRICT > > on data loss > > > 4) weak typing with new conversion rules > > > 5) some syntax to allow both one of 1)/2) and 3)/4)/5) > > > > > > i can take care of 3), 4) and 5) over the weekend, though for 4b) (see > > below) i would like to get some feedback from others > > > > > > other than that i agree that we have beat this horse long enough that > we > > can then pretty quickly move to a vote. that being said, i think we > should > > do the vote by allowing people to then sort the RFC's in order of > preference > > with the option of leaving options out that they want to veto. > > > > > > of course if 6) gets voted for we would then have to decide on which of > > the permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second > vote. > > > > > > ok .. i adjusted the weak type hinting RFC to cover 3) and 4). > > so i guess it would be nice if someone could create and RFC for 2) (as I > > guess the strict typing RFC covers 1)?) and if someone believes in a > > combined approach (Derick?) create an RFC for 5). > > if someone wants to do an SPL based exception approach, feel free to > create > > a new RFC. > > > > > http://wiki.php.net/rfc/splweaktypehintingwithautoboxing > Sorry for my poor english grammar, feel free to correct/expand/challenge > it. > > Tyrael >
Re: [PHP-DEV] Type hinting
I remember Marcus worked on something like that some time ago. Might still
be into SVN or somewhere I think.
Julien
On Sat, May 29, 2010 at 9:03 PM, Ferenc Kovacs wrote:
> On Sat, May 29, 2010 at 7:34 PM, Zeev Suraski wrote:
>
> > At 20:28 29/05/2010, Chris Stockton wrote:
> >
> > My biggest issue as a user is the fatal errors. Why are we blowing up on
> >> something that should throw some kind of useful argument exception? I
> end up
> >> in my applications using instanceof everywhere because their is
> important
> >> cleanup to be done before the end of the request. For example I can't
> afford
> >> for php to just blow up in our account setup script, we are reaching out
> to
> >> multiple non-transactional external resources. Some of our long running
> >> command line processes have the same issue. I am all for type hinting
> but
> >> the fatal errors or "catchabale" fatal errors are just silly. Exceptions
> >> make so much more sense to me.
> >>
> >
> > IMHO we shouldn't be getting to any kind of fatal error/exception
> > situation, which is why I like the idea of auto-conversion plus E_STRICT
> in
> > the 'weird conversion' scenarios (the API function shouldn't care - it
> got
> > what it asked for; The caller would get notified that he passed
> something
> > that probably doesn't make sense).
> > But as to why errors and not exceptions - we have a guideline that
> language
> > constructs don't through exceptions. It's up to users whether they want
> to
> > use exceptions or not.
> >
> >
> > Zeev
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> I'm thinking about the type hinting in php for a while, and there is my 2
> cent about this.
>
> As an API developer, I need a way, to easily force my input into a proper
> type, with ease, without dataloss, and without code duplication.
> As an API consumer, I don't want to bother much about my API calls, as long
> as my passed arguments are in the accepted form(I don't want to
> convert '123' into 123), and I don't want to create yet another custom
> error
> handler, to fetch the potentially triggered errors, and I cannot allow,
> that
> one unhandled catcable fatal error ruin my application.
>
> So basically I need type jugling(weak type hinting) + exceptions instead of
> catchable errors.
> But I know that the core should't throw exceptions, so we can't go to that
> direction.
>
> What if we introduce a new spl interface, which propose auto boxing for the
> scalar types + exceptions for the type missmatch.
> I mean, if you call that class with scalar arguments, the scalar values
> will
> be converted to the matching spl class instance.
> This way, you could hint your types for the interface without forcing the
> api consumer to bother to convert '123' to 123 before passing it to the
> method.
> But if the consumer passes '123abc' when I'm hinting SplInt, then it will
> throw an InvalidArgumentException or such.
>
> So for example:
>
> class foo implements WeakTypeHinting{
> public function bar(SplInt $baz){
> return $baz++;
> }
> }
>
> $foo = new foo;
> echo $foo->bar(1);
> // 2
> echo $foo->bar('2');
> // 3
> echo $foo->bar('3a')
> // InvalidArgumentException
>
> Feel free to discuss.
>
> Tyrael
>
Re: [PHP-DEV] The inconsistencies/flaws of PHP5's object model
On Wed, Nov 18, 2009 at 8:59 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I've just occured a syntax problem in the following script:
>>
>> > class C {
>> public $n = 1;
>> }
>> $o = new C();
>> $o->f = function () use ($o) {
>> echo $o->n;
>> };
>> $o->f();
>> ?>
>>
>> The result of this script is "Fatal Error: Call to undefined method
>> C::f()".
>> I don't know this is the expected result. After trying more tests of
>
> Yes, this is the expected result. PHP is not Javascript, sorry :) Methods
> and properties are different things in PHP, so the syntax assumes you refer
> to method when you call $o->f(). You could use other syntaxes if you need to
> use a property as callable (see call_user_function, etc.).
>
call_user_func(array($o,'f')); leads to fatal error, I think the same
internal mechanisms than $o->f() happens in call_user_func : the
closure gets ignored but like Stas said : this could lead to problems
with __get() and __call().
Anyway, for your use case to work, you should call $o->f->__invoke();
or call_user_func($o->f);
Julien.Pauli
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
