Re: [PHP-DEV] Fwd: Monotonic Time
> > > > Actually, it seems, that hrtime doesn't let you access the current > > > value, which is, well, quite a major use case, isn't it? > > > > > > Yes, that seemed weird to me, too. Did we miss anything, Anatol? > > > Yeah, I thought I did that already, but well ... The ext was more about > performance testing, at the start at least. I made some refactoring to it > yesterday, so it is now possible to implement an arbitrary userspace timer > using the HRTime\PerformanceCounter class. Maybe should add also > HRTime\Timer, but it should first get a thought about some good API > approach. > > The portable parts are bundled files timer.[h|c] in the hrtime repo, > supporting POSIX, Windows and Mac. They can be reused, or taken as an > example, for sure. Hi Anatol, Do you think we should merge hrtime into core or add a simple function just like microtime() to ext/standard? Regards, Niklas
[PHP-DEV] Re: [PHP-CVS] com php-src: Introduced "zend_type" - an abstraction for type-hinting representation.: Zend/zend_API.c Zend/zend_API.h Zend/zend_builtin_functions.c Zend/zend_compile.c Zend/ze
On 01/13/2017 09:37 AM, Dmitry Stogov wrote: Commit:141d1ba9801f742dc5d9ccd06e02b94284c4deb7 Author:Dmitry Stogov Fri, 13 Jan 2017 11:37:46 +0300 Parents: 28391c30ca008013267592ab2a2eebce3da3f3b0 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=141d1ba9801f742dc5d9ccd06e02b94284c4deb7 Log: Introduced "zend_type" - an abstraction for type-hinting representation. Great to see this make it into master so quickly. Thanks for your work on this! After this commit, however, PHPUnit stopped working with PHP 7.2: Fatal error: Uncaught TypeError: Argument 1 passed to PHPUnit_TextUI_TestRunner::__construct() must be an instance of PHPUnit_Runner_TestSuiteLoader or null, null given, called in /usr/local/src/phpunit/src/TextUI/Command.php on line 213 and defined in /usr/local/src/phpunit/src/TextUI/TestRunner.php:70 Here is how you can reproduce it: $ g...@github.com:sebastianbergmann/phpunit.git $ cd phpunit $ composer update --no-interaction --no-progress --no-ansi --no-suggest --optimize-autoloader --prefer-stable $ ./phpunit -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Introduced "zend_type" - an abstraction for type-hinting representation.: Zend/zend_API.c Zend/zend_API.h Zend/zend_builtin_functions.c Zend/zend_compile.c Zend/ze
Sorry, for breaking. I'll try fix this at evening (sorry, I don't have time right now). From: Sebastian Bergmann Sent: Friday, January 13, 2017 12:37:37 PM To: internals@lists.php.net Cc: Dmitry Stogov Subject: Re: [PHP-CVS] com php-src: Introduced "zend_type" - an abstraction for type-hinting representation.: Zend/zend_API.c Zend/zend_API.h Zend/zend_builtin_functions.c Zend/zend_compile.c Zend/zend_compile.h Zend/zend_execute.c Zend/zend_inheritance.c Zend/... On 01/13/2017 09:37 AM, Dmitry Stogov wrote: > Commit:141d1ba9801f742dc5d9ccd06e02b94284c4deb7 > Author:Dmitry Stogov Fri, 13 Jan 2017 11:37:46 > +0300 > Parents: 28391c30ca008013267592ab2a2eebce3da3f3b0 > Branches: master > > Link: > http://git.php.net/?p=php-src.git;a=commitdiff;h=141d1ba9801f742dc5d9ccd06e02b94284c4deb7 > > Log: > Introduced "zend_type" - an abstraction for type-hinting representation. Great to see this make it into master so quickly. Thanks for your work on this! After this commit, however, PHPUnit stopped working with PHP 7.2: Fatal error: Uncaught TypeError: Argument 1 passed to PHPUnit_TextUI_TestRunner::__construct() must be an instance of PHPUnit_Runner_TestSuiteLoader or null, null given, called in /usr/local/src/phpunit/src/TextUI/Command.php on line 213 and defined in /usr/local/src/phpunit/src/TextUI/TestRunner.php:70 Here is how you can reproduce it: $ g...@github.com:sebastianbergmann/phpunit.git $ cd phpunit $ composer update --no-interaction --no-progress --no-ansi --no-suggest --optimize-autoloader --prefer-stable $ ./phpunit
Re: [PHP-DEV] Fwd: Monotonic Time
On Fri, 13 Jan 2017 at 09:35 Niklas Keller wrote: > Hi Anatol, > > Do you think we should merge hrtime into core or add a simple function just > like microtime() to ext/standard? > > Regards, Niklas > It would be great if it could be a simple function, however it is going to be difficult to produce something cross-platform and meaningful with a single function. (I know Anatol has written portable code, I haven't looked at it but I assume it's wrapping the various structs used by i.e. performance counters, hrtime, etc.) I don't think we can get away from having an object-based implementation to wrap those internal structs, but I do think this is a useful addition regardless of how it's presented.
Re: [PHP-DEV] Fwd: Monotonic Time
2017-01-13 15:06 GMT+01:00 Leigh : > On Fri, 13 Jan 2017 at 09:35 Niklas Keller wrote: > > > Hi Anatol, > > > > Do you think we should merge hrtime into core or add a simple function > just > > like microtime() to ext/standard? > > > > Regards, Niklas > > > > It would be great if it could be a simple function, however it is going to > be difficult to produce something cross-platform and meaningful with a > single function. (I know Anatol has written portable code, I haven't looked > at it but I assume it's wrapping the various structs used by i.e. > performance counters, hrtime, etc.) > > I don't think we can get away from having an object-based implementation to > wrap those internal structs, but I do think this is a useful addition > regardless of how it's presented. > With timer.c it's very easy to have it as one function, in fact it's a simple static method currently doing exactly what I think it should probably do in core as a function. http://svn.php.net/viewvc/pecl/hrtime/trunk/hrtime.c?revision=341600&view=markup < Line 416. Any name suggestions? Regards, Niklas
Re: [PHP-DEV][RFC][VOTE] Throwable error code's type generalization
vote restarted
[PHP-DEV] Re: ext/gd: support creation of animated GIFs
Hi! On 10.01.2017 at 20:24, Andrea Faulds wrote: > Christoph M. Becker wrote: > >> On 09.01.2017 at 21:19, Andrea Faulds wrote: >> >>> Would this opaque object still allow you to use an arbitrary stream of >>> your choice? >>> >>> Also, like with imagepng() etc., could you stream the output to uh… >>> PHP's default output stream? (I'm not sure what it's called. The thing >>> that `echo` goes to.) >> >> It would be possible to allow either a stream URL or a stream to given, >> what would fit to image(png|jpeg|…)(). However, these are "stand-alone" >> functions which close the stream when they're finished, while the >> animated GIF writing functions would *allow* the stream to be >> manipulated by the userland developer, even though I can't see practical >> reason to do so. >> >> And, of course, we could also let the functions accept NULL to directly >> write to stdout. Passing in 'php://stdout' should have the same effect. > > Alright. > >> >>> If it does both, I don't have much objection. >>> >>> Mind you… is it really necessary to hide the stream from the user? >>> fopen() is not particularly hard to use, and there are (admittedly >>> niche) cases where you might want to handle the stream yourself. >> >> Are there really such cases? Should we sacrifice the safety of internal >> stream handling to support some (hypothetical?) use cases? > > In fairness, I'm not sure. I know animated GIF streaming has been tried > before, though I doubt if it's actually used at all these days. A more > reasonable case might be embedding an animated GIF in other binary data. > But that's a hypothetical. Okay. > What is the actual “safety” gain of not using streams? That you don't > need to use fopen() yourself? (PHP will close files for you.) I'm just > not super convinced there's a need for adding this extra layer. It's not about having to fopen() the stream – in my opinion at least that's a non-brainer. What is a minor issue though, is that either imagegifanimend() closes the stream automatically (what imagepng() and friends are doing), or not (in my opinion the proper solution, but inconsistent). The major issue for me would be the possibility that the user fiddles with the stream between imagegifanimbegin() and imagegifanimend() – in the worst case closing the stream, so imagegifanimend() would fail or had to catch that. Of course, that would be a programmer error, but nonetheless it would have to be documented, and I'm pretty sure that at least some devs would walk into this trap. Anyhow, thanks for the feedback. I'll see how to unify this in a single RFC (probably with secondary voting options). -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2017-01-12
Results for project PHP master, build date 2017-01-12 20:28:46-08:00 commit: c4e0ba0 previous commit:ec6b03a revision date: 2017-01-12 22:46:24+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.21% 0.96% 0.27% 7.62% :-| Drupal 7.36 cgi -T1 0.16% 0.37% 0.05% 4.73% :-| MediaWiki 1.23.9 cgi -T5000 0.07% 0.22% 1.29% 3.17% :-| bench.php cgi -T100 0.00% 0.13% 38.06% -10.75% :-| micro_bench.php cgi -T10 0.01% -0.01% 15.93% -0.18% :-| mandelbrot.php cgi -T100 1.57% -0.85% 30.81% -8.29% --- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2017-01-12/ Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
