On 31/08/13 14:13, Nikita Popov wrote:
Is there any particular reason why we only pass return_value_ptr to internal
functions if they have the ACC_RETURN_REFERENCE flag set?
Why can't we always provide the retval ptr, even for functions that don't
return by reference? This would allow
On 30/08/13 10:43, Julien Pauli wrote:
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison
ellison.te...@gmail.com mailto:ellison.te...@gmail.com wrote:
There's another one in string.c, in PHP_FUNCTION(pathinfo), that
could be applied as well, though there's little performance gain
On 27/08/13 10:40, Nikita Popov wrote:
On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Is there any particular reason why we only pass return_value_ptr to
internal functions if they have the ACC_RETURN_REFERENCE flag set?
Why can't we always provide the
Johannes,
Thanks, but I'll make some responses
On Mon, 2013-08-19 at 17:05 +0100, Terry Ellison wrote:
By way of a background. I've been doing a review of the exting code
base looking at how to establishing a roadmap extend OPcache
functionality across all supported OSes and SAPIs
On 20/08/13 16:50, Johannes Schlüter wrote:
snip Terry Ellison wrote:
PHP (unlike some language alternatives) seems to be doing little to
improve general performance, and the discussions related to
performance on this DL are almost non-existent.
Looking at any benchmark from 5.2 to 5.3 to 5.4
support these APIs. If we limited TSRM and OPcache support at PHP 5.6
to two code variants, POSIX + WIN32, surely this would still cover all
the major supported OSes?
//Terry Ellison
(*) GNU threads is still supported but it prevents utilisation of SMP
systems and there is a minimal performance
, and you are supporting it then
it doesn't belong on my suggested list. :-)
At the moment I did not follow recent commits to SAPI-related code, so I have
to closer look into it. Are there any RFCs related to changes coming in 5.6 for
OPcache?
Not currently.
-Original Message-
From: Terry
crankypuss wrote:
... I don't want to have to modify the interpreter at this point...
Sorry, but this list is for just this purpose, so you post does belong
on the DL.
Regards Terry
PS. read up on PHAR extensions and use of streams. There's nothing
stopping you specifying a phar or even a
it this way (see https://github.com/symfony/symfony-docs/) and I
like it very much. It is really easy to extend/update parts of the docu which
are not complete or outdated and I am sure that it is comfortable and
timesaving for the doc team, too.
+1
Regards Terry Ellison
to change one #ifdef
//Terry
On Jun 21, 2013, at 3:52 AM, Terry Ellison ellison.te...@gmail.com
mailto:ellison.te...@gmail.com wrote:
The Multi-Level Cache (MLC) OPcache fork typically delivers 80% of
the performance acceleration of standard OPcache for the CLI and GCI
SAPI modes. (OPCache
wider interest to the
list subscribers.
Thank-you and regards
Terry Ellison
Caveat: I've only tested this Alpha version on 64bit Linux
configurations for PHP 5.3 and 5.4, and would therefore like to limit
initial testing to these configurations at this stage.
--
PHP Internals - PHP Runtime
On 10/06/13 19:33, Nikita Popov wrote:
We just published some rather extensive documentation on internal object
orientation:
http://www.phpinternalsbook.com/classes_objects.html
This is part of a larger project aimed at documenting the engine and making
it accessible to new contributors.
On 10/06/13 09:20, Dmitry Stogov wrote:
Sorry for slow response.
I'm very busy with other work and have no time for MLC OPcache review.
I don't think we can include it into main tree before 5.5.0 release
anyway.
But in general I think we may include your work in the future releases.
Also,
, Terry Ellison te...@ellisons.org.uk
mailto:te...@ellisons.org.uk wrote:
Please treat this email by way of request for feedback from the
OPcache developers and anyone interested in influencing my next
steps on my https://github.com/TerryE/opcache fork of OPcache and
specifically
the disadvantages of
any compile-intensive optimization options.
So thank-you in anticipation for your feedback. I will do my utmost to
respond constructively to all comments. :-)
Regards Terry Ellison
PS. Apologies in advance: I am up country at my cottage on an Island
in the north Aegean
Rasmus,
snip
- Request 1 starts before the deploy and loads script A, B
- Deploy to a separate directory and the docroot symlink now points to here
- Request 2 starts and loads A, B, C
- Request 1 was a bit slow and gets to load C now
The issues that you raise about introducing atomic
On 23/03/13 06:29, Laruence wrote:
since Zend O+ has bundled into PHP since 5.5, and O+ is really a
bit faster than APC,
so people may want to migrate to O+, but there is no User Data
Cache in O+ ...
Laurence, you are correct that O+ doesn't provide data caching, but what
about
On 23/03/13 09:46, Matīss Roberts Treinis wrote:
Memcached is distributed caching system, where as APC's user data
cache is not. Memcached requires separate server instance (memcached)
to operate. APC does not.
Yes, but there is nothing to stop an admin of an application-dedicated
system or VM
On 02/03/13 08:39, Zeev Suraski wrote:
The current vote that's going on right now deals with putting the extension
into PHP itself. If that happens (which seems awfully likely at this
point), why do we need it in PECL?
My response to your Q is that there is probably going to be quite a lot
of
At what point is O+ reporting going to be possible through
https://bugs.php.net/ ?
I realize that this is a bit of a catch-22, but surely it would be
better to allow properly tracked open bug reporting sooner rather later?
Regards Terry
On 02/03/13 09:34, Pierre Joye wrote:
Having it in peck right now allows that. But as of now it is not a
PHP.net project so it makes little sense to have it listed there.
On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk
mailto:te...@ellisons.org.uk wrote:
At what point
On 02/03/13 17:42, Christopher Jones wrote:
I realize that this is a bit of a catch-22, but surely it would be
better to allow properly tracked open bug reporting sooner rather
later?
Bugs can (and have been) reported via
https://github.com/zend-dev/ZendOptimizerPlus/issues
On 03/02/13 15:27, Hans-Juergen Petrich wrote:
In this example (using php-5.4.11 on Linux) the memory will grow
non-stop:
for ( $fp = fopen('/dev/urandom', 'rb'); true;) {
eval ('$ano_fnc = function() {$x = '.bin2hex(fread($fp,
mt_rand(1, 1))).';};');
echo Mem usage:
Ramus, thanks for your detailed response.
NFS is so common for sharing files that ...
This is simply not true. I do have a fair bit of experience in this
field, and I don't know of any major sites that do this and I have
worked with a good chunk of the largest sites out there.
Eh??? Fortune
On 22/02/13 11:20, Ferenc Kovacs wrote:
My challenge is deciding (i) do I work on PHP 5.6 / 5.7 and the
corresponding beta APC version which at current rates of adoption
might have begin to have an impact in the community sometime in
the next 5 years, or (ii) work on a
On 19/02/13 01:30, Kevin Yung wrote:
In our environment, we use NFS for shared storage, we are using APC as well
with stat=0. In our setting, we also experiencing high number of stat()
calls on our file system. My initial finding of this problem is we enabled
the open_basedir setting. And there
Here is a counterpoint to that expressed by Lars. Many if not most
shared hosting providers don't offer PHP 5.4 yet. Ditto many
enterprises have yet to adopt it. The main reason? I think its that
old Backwards Compatibility issue that has been discussed heavily on
this DL.
When major
On 21/02/13 23:38, Rasmus Lerdorf wrote:
On 02/21/2013 03:15 PM, Brendon Colby wrote:
NFS is so common for sharing files that saying Wow, people are still
serving web files over NFS? is like saying Wow, people are still
using the ls command to list directory contents on Linux? I think NFS
is
On 20/02/13 08:26, Stas Malyshev wrote:
That depends of what your error handlers do. Some may write to log
files, etc. if not configured properly (since error_reporting setting
doesn't have to be considered in it). IIRC, for most of the cases O+
should be able to resolve all includes/requires
On 20/02/13 23:52, Brendon Colby wrote:
Terry,
Thanks for your detailed input. This is essentially what I did in my test setup.
APC is definitely critical to the performance of our site. I'm just
very curious to see how much impact the high number of getattr
operations coming from the
The point that this thread highlights is that apps developers /
administrators at both ends of the scale -- the enterprise and the
shared service user -- normally have little say over the infrastructure
architecture on which their application runs. In both these cases the
infrastructure will
On 19/02/13 09:36, Terry Ellison wrote:
The point that this thread highlights is that apps developers /
administrators at both ends of the scale -- the enterprise and the
shared service user -- normally have little say over the
infrastructure architecture on which their application runs
On 19/02/13 20:32, Stas Malyshev wrote:
Hi!
and IIRC mwiki does 4 of these on a page render. Here a pattern based
on (@include($file) == 1) is more cache-friendly.
This goes back to the fact that @ does not really disable errors - it
only disables reporting of the errors, but the whole
On 18/02/13 21:47, Brendon Colby wrote:
On Mon, Feb 18, 2013 at 4:32 PM, Damien Tournoud d...@damz.org wrote:
Assuming that those are relative includes, can you try with:
apc.canonicalize=0
apc.stat=0
Paths are absolute. stat=0 (and canonicalize=0 just to try it)
produced the same
On 15/02/13 01:59, Stas Malyshev wrote:
(A) The op-code optimization should be integrated into the core compiler
and enabled through a GC(compiler_option) to be available to *any*
opcode cache -- or to the application designer (by exposing these
options through an INI directive.
Most
On 14/02/13 18:24, Stas Malyshev wrote:
Are optimizations documented?
Not yet AFAIK.
No, but they are pretty self-explanatory. O+ is a _Zend_ extension
rather than a _PHP_ extension and this enables it to exploit extra
hooks (see the tail of ZendAccelerator.c) and specifically follow
On 10/02/13 06:50, Stas Malyshev wrote:
isn't the case with visualC, and PHP internal data structures compiled
with visualC and gcc are significantly different; for example hash keys
are 32 bits long on Windows and 64bits on *nix. Why aren't they 32bits,
Yes, they are different, because long
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
are now core to PHP performance, it should be
possible to implement a cache using hooks and interfaces exported
through a Zend header file and without recoding bits of the engine.
Optimizer+ should be an exemplar of such an approach.
Regards Terry Ellison
On 09/02/13 15:47, Pierre Joye wrote:
hi Remi
On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet r...@fedoraproject.org wrote:
About
http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
(For now, I have reverted this fix)
Here some explanations.
LONG_MAX is
On 10/02/13 03:25, Stas Malyshev wrote:
these onto the appropriate visualC / gcc types. As far as I can see,
PHP doesn't and seems to use long and int almost interchangeably which
PHP indeed does not use fixed-size types in zvals, etc. but it
definitely does not use long and int almost
the per-script caches and a repeat to run against the cache version).
Anyway, regards to you all, Terry Ellison
On 04/02/13 10:57, Ángel González wrote:
snip
The memory will stop growing (on my machine) at ~2491584 bytes and the
loop is able to run forever,
creating each eval() furthermore uniqe ano-function's but not
endless-filling Zend-internal tables.
but this still leaves the function record itself
Hi Terry and all
thank you very much for your response.
The only thing that confused me about what you say that the second
*doesn't* grow
Yes, about that i was [and am still :-)] also confused... why the 2nd
one won't grow *non-stop*
so I checked and it does -- just the same as the first.
On 30/01/13 00:54, Rasmus Lerdorf wrote:
On 01/29/2013 04:47 PM, Stas Malyshev wrote:
Hi!
which shows the dreaded zend_optimizerplus.inherited_hack which mimics
APC's autofilter hack. I'd love to get rid of this particular bit of
confusion/code complexity on the integration.
Ohh, this one.
45 matches
Mail list logo
