[PHP-DEV] Re: [PHP-QA] Parallel run-tests
On 21/05/2012 06:45, Nuno Lopes wrote: Hi Zoe, Thanks for undertaking this project! I just have a few concerns about this: - The speedup seems a bit low to me. Maybe with a higher number of extensions enabled it will improve?.. I don't think it will improve with a higher number of extensions. It _may_ improve as a result of someone doing some work on the tests are scheduled - but I wouldn't count on it. Looking at improving performance is important and I wanted to get some confirmation that it is faster, I think we have that level of confirmation now. However, if I'm the only person working on this, further performance work will come after complete implementation + debugging. - Is there any developer documentation available? If I wanted to do a change or a bug fix today, how could I do it? Lots - https://wiki.php.net/qa/runtests. I have just updated the Development section which has instructions on how to build and test the code. The 'Documentation' section has not been updated recently but I think it is still valid. - Can it be packaged as a single drop-in file replacement for run-tests.php? The deployment is very important to me. IMHO, the optimal solution would be to have a drop-in replacement for the current script, so that most developers wouldn't even notice the difference. Yes - totally agree. I think I experimented with packaging it as a .phar (so it would be called run-tests.phar, not run-tests.php), but it's so long ago that I can't remember. I have added it to the to-do list (https://wiki.php.net/qa/runtests/todos). - From previous emails exchanged in this thread, it seems that this new version requires a few extensions to run (gzip, soap??). This is not acceptable. The script must be able to run with --disable-all. Of course in that case the parallel version will fail. No, it doesn't. That was a stupid bug and I fixed it last night :-) Zoe Nuno -Original Message- From: zoe slattery Sent: Thursday, May 17, 2012 1:00 PM To: internals@lists.php.net ; PHP QA Subject: [PHP-QA] Parallel run-tests Hi Over the past couple of weeks I have updated the parallel run-tests (fixed a couple of minor bugs in the PHP code and the build.xml), it's now almost at the point where I could go ahead and implement the last pieces. Here is a summary and a few questions: 1. In rebasing the code the the dev't stream I found a number of tests with non-standard sections. My code checks test case structure and objects to anything non-standard, the current run-tests.php mainly ignores this kind of thing. I fixed up about 15 of these tests (see #62022) already - I'll fix the rest if there are no objections - I will open another bug report first. 2. If there is agreement to use this code it would make sense to replace the existing run-tests code with it, or rather, it would make no sense to try and maintain both versions. The new code is OO PHP, it's in http://git.php.net/repository/phpruntests.git, is there any problem with it staying there long term and maybe copying a run-tests.phar into the PHP source directory? I have no idea what the right answer is, suggestions welcome. 3. I ran a couple of small tests on my dual core Mac yesterday. For a standard set of tests, the parallel code ran in 207 seconds, sequential in 293 seconds and the standard run-tests.php took 298 seconds. This is an improvement but I suspect we could still do better by looking at the scheduling algorithm. At the moment it's very simple, we just assemble a list of directories with tests in and hand them out to processors till everything is done. Being able to handle tests that must be run in sequence (mysql, mysqli) will mean making some changes to this. So, perhaps we give an explicit list to p1 and let the scheduler distribute the rest of the tests? Or maybe we should have a 'process map' for all tests for extensions that are build by default? Again, suggestions welcome. 4. REDIRECTTEST still needs to be implemented, I understand how it works and this isn't (afaict) a major issue. 5. Testing. I'm able to do basic testing on Mac OSX and Linux. I really need access to an 8 way Linux system, or someone who has access and would be interested in looking at performance? Any volunteers? This is probably the most interesting part of the project :-) 6. Windows. I'm not in a position to do anything much with Windows except some very basic checks to make sure that the sequential version runs. The parallel code won't work because we used pcntl(), however I know that Stefan and George were keen to design the code so that a Windows solution could be implemented if anyone thought of one. If anyone wants to pick up this aspect I'd be happy to get them started. Zoe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Parallel run-tests
Hi, nice work, out of curiosity I tried on a VM with 24 virtual cores: Sequential new phpruntests: 29.6 seconds Parallel -z 4: 12.1 - 12.3 secs Parallel -z 8: 10.6 - 10.9 secs Parallel -z 16: 10.6 - 11.3 secs Parallel -z 24: 10.9 - 11.7 secs Btw I'm seeing this error: PHP Warning: Invalid argument supplied for foreach() in phpruntests/src/testrun/rtPhpTestRun.php on line 107 PHP Notice: Undefined offset: 1 in phpruntests/src/testrun/rtPhpTestRun.php on line 107 Devis
Re: [PHP-DEV] Re: [PHP-QA] Parallel run-tests
On 21/05/2012 08:59, Devis Lucato wrote: Hi, nice work, out of curiosity I tried on a VM with 24 virtual cores: Sequential new phpruntests: 29.6 seconds Parallel -z 4: 12.1 - 12.3 secs Parallel -z 8: 10.6 - 10.9 secs Parallel -z 16: 10.6 - 11.3 secs Parallel -z 24: 10.9 - 11.7 secs Cool - thanks! I'll add those points to the performance chart. At a quick look that fits pretty much with the other data. Out of curiosity, how many 'test groups' was it? Btw I'm seeing this error: PHP Warning: Invalid argument supplied for foreach() in phpruntests/src/testrun/rtPhpTestRun.php on line 107 PHP Notice: Undefined offset: 1 in phpruntests/src/testrun/rtPhpTestRun.php on line 107 My bad. I started to implement REDIRECTTEST and checked in some initial changes, I can see what I've done wrong and will fix later today. Zoe Devis
[PHP-DEV] zend_execute_internal hook missing from PHP 5
Hi,
it recently came to my attention that the function whitelist and blacklist
feature inside Suhosin is easily bypassable since PHP 5.0.
The reason for this is that PHP is no longer calling the
zend_execute_internal() hook if a function is called from another function (via
zend_call_function)
In the days of PHP 4 the code looked like this:
if (!zend_execute_internal) {
((zend_internal_function *)
EX(function_state).function)-handler(EX(opline)-extended_value,
EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, 1 TSRMLS_CC);
} else {
zend_execute_internal(execute_data, 1 TSRMLS_CC);
}
Nowadays (since PHP 5.0) the code was moved from call_user_function_ex to
zend_call_function and just looks like this:
((zend_internal_function *)
EX(function_state).function)-handler(fci-param_count, *fci-retval_ptr_ptr,
fci-retval_ptr_ptr, fci-object_ptr, 1 TSRMLS_CC);
While this has no immediate impact for average PHP users, it basically kills
the possibility for an extension like Suhosin to catch all function starts.
This should also be a problem for your DTRACE support. And IIRC Xdebug was
hooking this point (at least in the past), too.
My suggestion is to change the code to call the hook again.
Regards,
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5
On Mon, 21 May 2012, Stefan Esser wrote: While this has no immediate impact for average PHP users, it basically kills the possibility for an extension like Suhosin to catch all function starts. This should also be a problem for your DTRACE support. And IIRC Xdebug was hooking this point (at least in the past), too. Indeed. And it finally explains why functions called from array_map() didn't show up in function traces anymore! My suggestion is to change the code to call the hook again. Yes, I'd like that too. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5
Sent from my iPhone
在 2012-5-21，18:42，Stefan Esser stefan.es...@sektioneins.de 写道：
Hi,
it recently came to my attention that the function whitelist and blacklist
feature inside Suhosin is easily bypassable since PHP 5.0.
The reason for this is that PHP is no longer calling the
zend_execute_internal() hook if a function is called from another function
(via zend_call_function)
In the days of PHP 4 the code looked like this:
if (!zend_execute_internal) {
((zend_internal_function *)
EX(function_state).function)-handler(EX(opline)-extended_value,
EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, 1 TSRMLS_CC);
} else {
zend_execute_internal(execute_data, 1 TSRMLS_CC);
}
Nowadays (since PHP 5.0) the code was moved from call_user_function_ex to
zend_call_function and just looks like this:
((zend_internal_function *)
EX(function_state).function)-handler(fci-param_count, *fci-retval_ptr_ptr,
fci-retval_ptr_ptr, fci-object_ptr, 1 TSRMLS_CC);
While this has no immediate impact for average PHP users, it basically kills
the possibility for an extension like Suhosin to catch all function starts.
Actually, there is one, use user opcode handler hook the fcall series
opcodes, that is how I did in taint extension.
http://svn.php.net/viewvc/pecl/taint/trunk/taint.c?view=markuppathrev=325586
line 995
Thanks
This should also be a problem for your DTRACE support. And IIRC Xdebug was
hooking this point (at least in the past), too.
My suggestion is to change the code to call the hook again.
Regards,
Stefan
--
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] zend_execute_internal hook missing from PHP 5
Hi, While this has no immediate impact for average PHP users, it basically kills the possibility for an extension like Suhosin to catch all function starts. Actually, there is one, use user opcode handler hook the fcall series opcodes, that is how I did in taint extension. From what I can see your taint extension also does not catch functions called by call_user_func() or array_map() or or or… Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5
发自我的 iPad 在 2012-5-21，21:05，Stefan Esser stefan.es...@sektioneins.de 写道： Hi, While this has no immediate impact for average PHP users, it basically kills the possibility for an extension like Suhosin to catch all function starts. Actually, there is one, use user opcode handler hook the fcall series opcodes, that is how I did in taint extension. From what I can see your taint extension also does not catch functions called by call_user_func() or array_map() or or or… I just want to say there is a way in theory , If you want a 100% intercept that you can also use override call_user_function additionally, which is also what I did to mark some function's return value in taint extension. Of course it's a little ugly, but it works :) Thanks Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] memory usage ouchy
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
?php
define('NUM_TESTS', 1000);
$before = memory_get_usage(true);
$test = array();
class Foo
{
public $;
public $;
public $;
public $;
}
$bytes = 0;
for ($i=0; $iNUM_TESTS; $i++) {
$foo = new Foo;
$foo- = 'a';
$foo- = 'b';
$foo- = 'c';
$foo- = 'd';
$bytes += 4;
$test[] = $foo;
}
$after = memory_get_usage(true);
header('Content-type: text/plain');
echo ($after-$before).' bytes used; '.$bytes.' bytes of information stored.';
Output is this:
786432 bytes used; 4000 bytes of information stored.
I know this an extreme example, I just did it to see if what I
suspected was actually correct.
How come it's necessary to store the property-names of every property
in every object? For properties that have been defined in classes, why
can't they be stored in a more efficient manner? (using lookup tables)
I know the nature of PHP is dynamic, and I know that dynamic
properties would have to be stored in a key/value form internally...
but if you look at modern PHP software, dynamic properties is actually
something very few people use.
My suspicion is that all this memory-overhead has performance
implications as well? Allocating and deallocating memory for all of
these repeated property-names, it can't be very efficient?
I don't know much about the inner workings of PHP or C in general, but
if the property-names are in deed stored repeatedly, and if the
string-type uses a pointer, wouldn't it possible to point all of the
property-name strings to same address in memory, sharing the
property-name strings, instead of storing them repeatedly?
Just a thought...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Yeah, dynamic properties get used by default every time you json_decode something, to take a random example. String folding could be used, but that would require a hashtable lookup and would probably be slower than allocation (at least until you started to swap). Worth testing maybe. Or... when you instantiate an object, it still looks like a hash, but declared property names are initialized to point at shared strings. Dynamic property names aren't. When the object is reclaimed, the declared properties are removed first to prevent double deallocations, and then the dynamic properties are destroyed. I'm suggesting a lot of work here I'm sure, but this latter idea seems like it might yield a large memory usage improvement. On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persist context across threads?
On Mon, May 14, 2012 1:47 pm, David Rueter wrote: I am interested in preserving the complete PHP context for a thread (globals, variables, interpreter, etc.--everything) for later access from a different thread. What would be involved in this? It seems like: 1) Avoid calling ts_free_thread 2) Call tsrm_set_interpreter_context from new thread Is it safe to assume that the context of a terminated thread will not be destroyed or overwritten as long as ts_free_thread is not called? I don't really know what I'm talking about, but nobody has answered yet... For starters, not all extensions are thread-safe. I would expect that to mean that anything actively using those extensions saved state in another thread is a segfault waiting to happen. For security reasons and sheer plain cussedness, I don't think you're going want and/or get any resource (mysql connection/result/etc, gd images, file handles, etc) survive to the next thread. A mysql connection, for example, is opened with a specific user/pass. Another thread picking this up could probably abuse that, as I understand it. Finally, your question begs another question: Why do you want to do this? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Thanks for clarifying that. Sounds like a huge win. On Mon, May 21, 2012 at 3:13 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
I ran this script on 5.3.13, and it reported: 786432 bytes used On 5.4.3, it reported: 262144 bytes used That is definitely a significant improvement. Objects are still a lot bigger than their contents. I don't expect they would ever shrink to the size of their contents exactly or even all that close of course. On Mon, May 21, 2012 at 3:25 PM, Tom Boutell t...@punkave.com wrote: Thanks for clarifying that. Sounds like a huge win. On Mon, May 21, 2012 at 3:13 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Hi! 262144 bytes used That is definitely a significant improvement. Objects are still a lot bigger than their contents. I don't expect they would ever shrink to the size of their contents exactly or even all that close of course. Hashtables and zvals have overhead. So if you store 4-byte value, you have: zval wrapper - 16 bytes allocation unit - 8 bytes IIRC hashtable bucket - 36 bytes So you are already at 60 bytes per value. That's on 32-bit, on 64-bit due to pointers and longs being wider, probably almost double that. Then also add the storage for the key itself. If you need more memory-efficient data storage, something like SplFixedArray may help. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
Hi Rafael, hope it’s ok I've reopened the vote temporarily, but you’ve got the missing vote. Am 21.05.2012 um 01:05 schrieb Rafael Dohms: On Mon, May 21, 2012 at 12:44 AM, Pierre Joye pierre@gmail.com wrote: See the previous mails, as long as other voters agree to change their votes to empty only, we are done. If my math does not fail me, we needed one more vote to have the 2/3 mentioned. Anthony has changed his vote, i think we are good to go. 20 votes = 2/3 = 13.3 So if we round down, the vote originally passed, and in any case Anthony makes it 14, so that should resolve any doubts Also, for future votes we need to make this rule clear: does 13.3 mean we need 13 votes or 14 votes to pass? In which case, this whole thread might actually have been for nothing since the vote had already passed. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- 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] memory usage ouchy
Adding/removing properties at runtime is great if you want obscure, unmaintainable code and don't think an IDE is useful. So to make my previous statement more precise, dynamic properties are not widely used in respectable modern codebases, and is generally something a reputable developer would frown upon. Yes, some codebases (e.g. Drupal) rely on this extensively, but modern frameworks generally do not - in fact, they often take measures to ensure that exceptions are thrown if you try to access a property that has not been formally defined. For that matter, most ORMs (a typical example of where dynamic properties would come in handy) don't rely on dynamic properties either - they rely on __get() and __set() and store the actual values in a single property, as an array. So even for highly dynamic components in modern frameworks, this is not a feature that is often used. Drupal-development aside, and perhaps some XOOPS-development back in the dark ages, I can't actually recall when I've used dynamic properties. I suddenly realize why certain heavily-used classes in the Yii framework have obscure property-names like $_m and $_p ... they're trying to save memory. Not really logical that you should have to compromise legible code in favor of saving memory. Makes me wonder if this issue could be addressed, killing two birds with one stone. Since the dynamic aspect is an inconvenience to many developers, and since it causes memory-overhead whether they make use of this feature or not, how about introducing a non-dynamic alternative base-class that actually throws if you access properties that have not been defined? This wouldn't change the way PHP objects work by default, but would lighten the memory-overhead in a lot of modern frameworks, and possibly speed up property-access too, since you can have a flat look-up table for class-properties; and could eliminate the need for an object or component base-class in frameworks... On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Rasmus, isn't your concern about the impact of dynamic property support on developers who don't actually use it a nonissue in 5.4, where properties that aren't dynamic are stored as a flat array? On Mon, May 21, 2012 at 4:52 PM, Rasmus Schultz ras...@mindplay.dk wrote: Adding/removing properties at runtime is great if you want obscure, unmaintainable code and don't think an IDE is useful. So to make my previous statement more precise, dynamic properties are not widely used in respectable modern codebases, and is generally something a reputable developer would frown upon. Yes, some codebases (e.g. Drupal) rely on this extensively, but modern frameworks generally do not - in fact, they often take measures to ensure that exceptions are thrown if you try to access a property that has not been formally defined. For that matter, most ORMs (a typical example of where dynamic properties would come in handy) don't rely on dynamic properties either - they rely on __get() and __set() and store the actual values in a single property, as an array. So even for highly dynamic components in modern frameworks, this is not a feature that is often used. Drupal-development aside, and perhaps some XOOPS-development back in the dark ages, I can't actually recall when I've used dynamic properties. I suddenly realize why certain heavily-used classes in the Yii framework have obscure property-names like $_m and $_p ... they're trying to save memory. Not really logical that you should have to compromise legible code in favor of saving memory. Makes me wonder if this issue could be addressed, killing two birds with one stone. Since the dynamic aspect is an inconvenience to many developers, and since it causes memory-overhead whether they make use of this feature or not, how about introducing a non-dynamic alternative base-class that actually throws if you access properties that have not been defined? This wouldn't change the way PHP objects work by default, but would lighten the memory-overhead in a lot of modern frameworks, and possibly speed up property-access too, since you can have a flat look-up table for class-properties; and could eliminate the need for an object or component base-class in frameworks... On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] array_part()
First, I'd like to announce the native implementation is available on github: https://github.com/cataphract/php-src/compare/array_part Please review this feature BEFORE voting starts. Unless something comes up that has to be dealt with until then, I want to start voting on Monday, 28th May. Now my answer to Richard: On Mon, 21 May 2012 21:30:24 +0200, Richard Lynch c...@l-i-e.com wrote: On Mon, May 14, 2012 9:03 am, Gustavo Lopes wrote: * array_slice() can preserve keys, array_part() cannot because when collapsing levels this would mean the possibility of overwriting elements. A predictable LIFO or FIFO for any collapsed keys would be reasonable, and probably not much more work to implement. By LIFO I mean that the last value to be put under a key would win I think that would be the most natural. Such a behavior would be possible and would not be difficult to implement. However, it raises questions that are not easy to answer like: - should it keep the first or the last keys? Or perhaps it could instead collect all the elements under a new array. - should the behavior for numeric keys differ from that of string keys (perhaps in a array_merge way?) Since the path to add this behavior in the future is straightforward (add another optional argument, like in array_slice), not including it causes little damage in terms of future growth. On the other hand, my hope is that limiting the current design decisions to a easy subset may allow this to be merged rapidly. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 10:36 PM, Lars Strojny l...@strojny.net wrote: Hi Rafael, hope it’s ok I've reopened the vote temporarily, but you’ve got the missing vote. Even better, get this on clean papers. thanks. But i would still like Pierre and others involved with voting to clear up the point about rounding up or down. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, 21 May 2012 23:18:03 +0200, Rafael Dohms lis...@rafaeldohms.com.br wrote: On Mon, May 21, 2012 at 10:36 PM, Lars Strojny l...@strojny.net wrote: hope it’s ok I've reopened the vote temporarily, but you’ve got the missing vote. Even better, get this on clean papers. thanks. But i would still like Pierre and others involved with voting to clear up the point about rounding up or down. There is nothing unclear about a 2/3 majority is required. 2/3 of all the votes need not be a integer, but that doesn't mean you can't compare it to an integer. If this still doesn't answer your question, please refer to how this works in virtually every election in the world. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 11:25 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: There is nothing unclear about a 2/3 majority is required. 2/3 of all the votes need not be a integer, but that doesn't mean you can't compare it to an integer. If this still doesn't answer your question, please refer to how this works in virtually every election in the world. So we are counting half people now, good i hear Tyrion the Imp going around internals, good. But great that is an answer, an edgy one with unneeded aggressiveness in my opinion, but i guess someone had to ask and deal with the attitude. I'll just step away again. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
What about a magic interface instead of a new base class, in a similar vein to the existing Array Access and Serializable interfaces. NonDynamic perhaps? On Mon, May 21, 2012 at 5:09 PM, Tom Boutell t...@punkave.com wrote: Rasmus, isn't your concern about the impact of dynamic property support on developers who don't actually use it a nonissue in 5.4, where properties that aren't dynamic are stored as a flat array? On Mon, May 21, 2012 at 4:52 PM, Rasmus Schultz ras...@mindplay.dk wrote: Adding/removing properties at runtime is great if you want obscure, unmaintainable code and don't think an IDE is useful. So to make my previous statement more precise, dynamic properties are not widely used in respectable modern codebases, and is generally something a reputable developer would frown upon. Yes, some codebases (e.g. Drupal) rely on this extensively, but modern frameworks generally do not - in fact, they often take measures to ensure that exceptions are thrown if you try to access a property that has not been formally defined. For that matter, most ORMs (a typical example of where dynamic properties would come in handy) don't rely on dynamic properties either - they rely on __get() and __set() and store the actual values in a single property, as an array. So even for highly dynamic components in modern frameworks, this is not a feature that is often used. Drupal-development aside, and perhaps some XOOPS-development back in the dark ages, I can't actually recall when I've used dynamic properties. I suddenly realize why certain heavily-used classes in the Yii framework have obscure property-names like $_m and $_p ... they're trying to save memory. Not really logical that you should have to compromise legible code in favor of saving memory. Makes me wonder if this issue could be addressed, killing two birds with one stone. Since the dynamic aspect is an inconvenience to many developers, and since it causes memory-overhead whether they make use of this feature or not, how about introducing a non-dynamic alternative base-class that actually throws if you access properties that have not been defined? This wouldn't change the way PHP objects work by default, but would lighten the memory-overhead in a lot of modern frameworks, and possibly speed up property-access too, since you can have a flat look-up table for class-properties; and could eliminate the need for an object or component base-class in frameworks... On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- 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] [VOTE] Vote change for empty() RFC
On Mon, 2012-05-21 at 23:48 +0200, Rafael Dohms wrote: So we are counting half people now, good i hear Tyrion the Imp going around internals, good. I tried to stay away from voting but well, simple math: Assume 5 votes. Then 3 is less then 2/3 of all votes and 4 is at least 2/3 (more mathematical: x = 2/3 * 5). No need to count half people or such. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 2:48 PM, Rafael Dohms lis...@rafaeldohms.com.brwrote: On Mon, May 21, 2012 at 11:25 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: There is nothing unclear about a 2/3 majority is required. 2/3 of all the votes need not be a integer, but that doesn't mean you can't compare it to an integer. If this still doesn't answer your question, please refer to how this works in virtually every election in the world. So we are counting half people now, good i hear Tyrion the Imp going around internals, good. But great that is an answer, an edgy one with unneeded aggressiveness in my opinion, but i guess someone had to ask and deal with the attitude. I'll just step away again. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think what Stas was saying is that rounding is not actually necessary when 2/3 results in a non-integer because the number of people voting will always be an integer regardless. In other words, because the requirement is it must be greater than or equal to as opposed to just must be equal to, then it's really a non-issue. For example, let's say that 10 people are voting. 2/3 majority is required. 6 people vote yes and 4 people vote no. That's 60% Because 60% 60.66...%, the vote fails. On the other hand, if 7 people vote yes and 3 vote no, then we're at 70%. And since 70% = 60.66...%, the vote passes. Notice how, in both cases, we did not need to round either of the numbers to do the comparison. It's either greater than or equal to the requirement or it's not. That being said, yeah the response you got did seem a bit overly hostile IMHO. --Kris
[PHP-DEV] Re: internals Digest 21 May 2012 21:48:46 -0000 Issue 2690
oh, wow! so this was already implemented in 5.4, and without introducing some kind of base-class to enable it. who knew... fantastic, thanks for the info! case closed :-) - Rasmus From: Gustavo Lopes glo...@nebm.ist.utl.pt To: internals@lists.php.net Cc: Date: Mon, 21 May 2012 21:13:52 +0200 Subject: Re: [PHP-DEV] memory usage ouchy On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array.
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
Ah, this is why one should trust a coder over a butler: http://www.ask.com/answers/112530521/5-people-are-voting-what-is-2-3-s-of-a-majority Ugh. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 at 3:22 PM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: Ah, this is why one should trust a coder over a butler: http://www.ask.com/answers/112530521/5-people-are-voting-what-is-2-3-s-of-a-majority Ugh. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Lol well I guess that answers another question I had: What kind of person still uses Ask Jeeves?! (Answer: A really, really stupid person) --Kris
Re: [PHP-DEV] memory usage ouchy
No offense intended, but if you've got so many OOP objects flying around that they are sucking down that much memory... You probably need to refactor your code and just don't do that Just my opinion. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Parallel run-tests
Alright, thanks for the reply! I'll try to have a look at the code and give it a try next weekend. Nuno -Original Message- From: zoe slattery Sent: Monday, May 21, 2012 8:26 AM Subject: Re: [PHP-QA] Parallel run-tests On 21/05/2012 06:45, Nuno Lopes wrote: Hi Zoe, Thanks for undertaking this project! I just have a few concerns about this: - The speedup seems a bit low to me. Maybe with a higher number of extensions enabled it will improve?.. I don't think it will improve with a higher number of extensions. It _may_ improve as a result of someone doing some work on the tests are scheduled - but I wouldn't count on it. Looking at improving performance is important and I wanted to get some confirmation that it is faster, I think we have that level of confirmation now. However, if I'm the only person working on this, further performance work will come after complete implementation + debugging. - Is there any developer documentation available? If I wanted to do a change or a bug fix today, how could I do it? Lots - https://wiki.php.net/qa/runtests. I have just updated the Development section which has instructions on how to build and test the code. The 'Documentation' section has not been updated recently but I think it is still valid. - Can it be packaged as a single drop-in file replacement for run-tests.php? The deployment is very important to me. IMHO, the optimal solution would be to have a drop-in replacement for the current script, so that most developers wouldn't even notice the difference. Yes - totally agree. I think I experimented with packaging it as a .phar (so it would be called run-tests.phar, not run-tests.php), but it's so long ago that I can't remember. I have added it to the to-do list (https://wiki.php.net/qa/runtests/todos). - From previous emails exchanged in this thread, it seems that this new version requires a few extensions to run (gzip, soap??). This is not acceptable. The script must be able to run with --disable-all. Of course in that case the parallel version will fail. No, it doesn't. That was a stupid bug and I fixed it last night :-) Zoe Nuno -Original Message- From: zoe slattery Sent: Thursday, May 17, 2012 1:00 PM To: internals@lists.php.net ; PHP QA Subject: [PHP-QA] Parallel run-tests Hi Over the past couple of weeks I have updated the parallel run-tests (fixed a couple of minor bugs in the PHP code and the build.xml), it's now almost at the point where I could go ahead and implement the last pieces. Here is a summary and a few questions: 1. In rebasing the code the the dev't stream I found a number of tests with non-standard sections. My code checks test case structure and objects to anything non-standard, the current run-tests.php mainly ignores this kind of thing. I fixed up about 15 of these tests (see #62022) already - I'll fix the rest if there are no objections - I will open another bug report first. 2. If there is agreement to use this code it would make sense to replace the existing run-tests code with it, or rather, it would make no sense to try and maintain both versions. The new code is OO PHP, it's in http://git.php.net/repository/phpruntests.git, is there any problem with it staying there long term and maybe copying a run-tests.phar into the PHP source directory? I have no idea what the right answer is, suggestions welcome. 3. I ran a couple of small tests on my dual core Mac yesterday. For a standard set of tests, the parallel code ran in 207 seconds, sequential in 293 seconds and the standard run-tests.php took 298 seconds. This is an improvement but I suspect we could still do better by looking at the scheduling algorithm. At the moment it's very simple, we just assemble a list of directories with tests in and hand them out to processors till everything is done. Being able to handle tests that must be run in sequence (mysql, mysqli) will mean making some changes to this. So, perhaps we give an explicit list to p1 and let the scheduler distribute the rest of the tests? Or maybe we should have a 'process map' for all tests for extensions that are build by default? Again, suggestions welcome. 4. REDIRECTTEST still needs to be implemented, I understand how it works and this isn't (afaict) a major issue. 5. Testing. I'm able to do basic testing on Mac OSX and Linux. I really need access to an 8 way Linux system, or someone who has access and would be interested in looking at performance? Any volunteers? This is probably the most interesting part of the project :-) 6. Windows. I'm not in a position to do anything much with Windows except some very basic checks to make sure that the sequential version runs. The parallel code won't work because we used pcntl(), however I know that Stefan and George were keen to design the code so that a Windows solution could be implemented if anyone thought of one. If anyone wants to pick up this aspect I'd be happy to get them started. Zoe -- PHP Internals
