Re: [PHP-DEV] Re: PHP 5.6 Process
On 10/17/2013 10:19 PM, Ferenc Kovacs wrote: On Thu, Oct 17, 2013 at 5:29 PM, Pierre Joye wrote: On Thu, Oct 17, 2013 at 7:56 AM, Michael Wallner wrote: On 17 October 2013 16:29, Felipe Pena wrote: +1 for Ferenc Kovacs. (is it a voting thread? :D) +1 (let's make it a good ol' one :)) +1 for both -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, thank you guys for the support, it means a lot! +1. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improved performance of array_maerge() and func_get_args()
makes sense. thanks :) Dmitry. On Wed, Oct 23, 2013 at 5:52 PM, Nikita Popov wrote: > On Wed, Oct 23, 2013 at 2:36 PM, Dmitry Stogov wrote: > >> Hi, >> >> I'm proposing two simple patches that eliminate a lot of useless zval >> copying. >> For example they remove only about 800 calls to zend_hash_copy() (25%) on >> each request to wordpress-3.6.0 home page and make it 2-4% faster. >> >> It's not a questions about master branch, but I think it is also safe to >> commit them into PHP-5.4 and PHP-5.5. >> >> Any objections? >> >> https://gist.github.com/dstogov/7117623 >> >> https://gist.github.com/dstogov/7117649 >> >> Thanks. Dmitry. >> > > No objection, just quick note on func_get_args patch: You can use > SEPARATE_ARG_IF_REF there, so the code in the loop body is: > > zval *arg = *(p-(arg_count-i)); > SEPARATE_ARG_IF_REF(arg); > zend_hash_next_index_insert(Z_ARRVAL_P(return_value), &arg, > sizeof(zval *), NULL); > > Nikita >
Re: [PHP-DEV] Re: Fix for bug #50333
Hi Dmitry,
On Mon, October 21, 2013 14:30, Dmitry Stogov wrote:
> Hi,
>
>
> I don't have strong opinion about the patch.
> I thought malloc() -> emalloc() change might improve PHP performance in
> general, but unfortunately it doesn't. On the other hand the patch is quite
> big and introduces source level incompatibility.
>
> The patch is not complete. At least it misses this chunk:
>
>
> --- a/sapi/cgi/cgi_main.c
> +++ b/sapi/cgi/cgi_main.c
> @@ -1396,7 +1396,7 @@ static void init_request_info(fcgi_request *request
> TSRMLS_DC)
> } else {
> SG(request_info).request_uri =
> env_script_name; }
> - free(real_path);
> + efree(real_path);
> }
> } else {
> /* pre 4.3 behaviour, shouldn't be used but
> provides BC */
>
> It's also much better to use do_alloca() instead of tsrm_do_alloca() (the
> patch changed them to less efficient emalloc()). May be if you change it,
> we would see improvement :)
>
> As I said, currently, the patch doesn't significantly affect performance
> of non-thread-safe build on Linux.
>
>
> master patched improvement Blog (req/sec) 106.1 105.1 -0.94% drupal
> (req/sec) 1660.5 1668.6 0.49% fw (req/sec) 231.7 227.499 -1.81% hello
> (req/sec) 11828.8 11980.5 1.28% qdig (req/sec) 470 477.3 1.55% typo3
> (req/sec) 580.1 579.3 -0.14% wordpress (req/sec) 185.9 188.5 1.40% xoops
> (req/sec) 130 131.2 0.92% scrum (req/sec) 185.199 185 -0.11% ZF1 Hello
> (req/sec) 1154.7 1155.2 0.04% ZF2 Test (req/sec) 248.7 250.7 0.80%
> Thanks. Dmitry.
>
>
>
>
> On Fri, Oct 18, 2013 at 7:33 PM, Anatol Belski wrote:
>
>
>> Hi,
>>
>>
>> the pull request https://github.com/php/php-src/pull/500 fixing the bug
>> #50333 is ready to review. Manual tests done so far on linux and
>> windows in TS and NTS mode with CLI and Apache show no regression. The
>> performance tests are to be done yet.
>>
>> Regards
>>
>>
>> Anatol
>>
thanks for the comments, the CGI part is fixed in the same patch.
While investigating on how to go further with your suggestion, I've yet a
couple of open questions.
The reason for moving files into Zend, as I can see from the original
patch is, that the tsrm_init has to happen after Zend memory manager init
in order to use the e* function family. It has to be true also for the
do_alloca() case as when the stack size was exceeded, it'll fallback to
emalloc(). For that reason, I'd rather implement your suggestion into the
existing patch as it's quicker just to see if it'd make sense at all. If
it would, tsrm files can be moved back into TSRM/ and one can look for
magic to initialize it in the right order.
It'd of course make sense to convert everything for do_alloca() usage,
just a replace for tsrm_do_alloca would already work, but ... there are
some places in the original codelike
http://lxr.php.net/xref/PHP_TRUNK/TSRM/tsrm_virtual_cwd.c#493 where malloc
is used. Or virtual_file_ex which is using realloc(), with do_alloca that
memory should be probably just left unfreed on the stack? Do you generally
think i should touch those places, would it be ok to leave them alone for
now for the tests? As otherwise it might need signature change of some
functions, it's about use_heap when the stack size is exceeded to avoid
memory leaks.
When I look here http://lxr.php.net/xref/PHP_TRUNK/Zend/zend.h#200 , only
some GNU based platform profits from alloca() on both TS and NTS. Some
others are only active with NTS only. Is there a particular reason for
that? I think that macros could be refactored at least for the Windows
part, as this page
http://msdn.microsoft.com/en-us/library/5471dc8s(v=vs.110).aspx deprecates
_alloca nowadays.
Also wondering why you was doing NTS perf tests, as the ticket is about
improvement for multi-threaded envs. Nevertheless the overall improvement
were even better of course :)
Regards
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
On 10/22/2013 07:32 PM, Patrick Schaaf wrote: Am 22.10.2013 20:07 schrieb "Joe Watkins" : You can catch exceptions, and log them. You can do that without impacting everything around you, you can do that, or whatever else you like. You can do that handling when you have only a few toplevel scripts, like when you have a setup with a small number of toplevel controllers and almost no CLI stuff around. But due to the scoped nature of try/catch you cannot reasonably / painlessly do that when you have 270 toplevel web and CLI entry points that then each need such a try/catch block. Also, there is the problem with catch (Exception) blocks, which you might easily dismiss as bad form, but which I'm sure are widespread in the field - I certainly know they are in our codebase... On the other hand, setup of an assertion-failed callback can easily go into an auto_prepend file, or into any other standard include (autoloader or something) you might have - exactly because it is something done on the global level instead of the scoped try/catch requirement. And IF you like the exception thing you can make that callback throw whatever you like - but you do not force that model on everybody. Furthermore such an assertion-failed callback has exactly the same change of looking at backtraces, so touting that as a singular feature of the exception approach is not valid. Finally, with the exception approach it is simply not true that it will completely go away in production - because these try/catch blocks will be present for any code that wants to handle the issue, and you cannot make those go away. I'm all for an assert alternative that works with expressions instead of eval, and that completely goes away in the opcode (cache) when disabled in production. best regards Patrick I was pretty explicit: used properly. We are going round in circles, discussing what assertion should be used for, again. Production code should _NOT_ have catch blocks everywhere to manage exceptions that will NEVER be thrown, obviously. assertion is a debug and development feature, if you take code to production that catches exceptions that your configuration does not allow to be thrown then that's pretty silly. assertion should be used during development, in development environments where it is enabled, by the time your code goes to production it should not suffer ExpectationExceptions and cannot anyway. I think this thread and the RFC now contains enough information regarding exceptions, it is now covered ground. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug tracker stats oddity
Hi, It felt a bit weird to report a bug about the bug tracker, so I decided to post it here. I came across this random bug: https://bugs.php.net/bug.php?id=64386 The stats are: Votes:105Avg. Score:2.1 ± 1.0Reproduced:1 of 12 (8.3%)Same Version:25769803765 (2576980376500.0%)Same OS:30064771059 (3006477105900.0%) That doesn't look quite kosher, unless 5x the world's population has had the same OS ;-) -- -- Tjerk
