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 message is
generated and goes all the cycle up to the actual error reporting before
being suppressed. I've tried to address this problem a number of times
but looks like there's really no way to do it without sacrificing some
parts of current error reporting such as track_errors.
Yup, in this scenario we're trading off two things. What the pattern is
saying is if the source file exists then compile it. However, if the
file exists, in say 90+% of the cases, and the code is often cached then
the file_exists check generates I/O that isn't needed if the file is
already APC (or O+ / xcache) cached. Yup if the file is missing then
the error is generated and trapped in the reporting cycle, but the final
result is that the result is false and the false==1 fails. Other than
the wasted cycles in running up this stack, there aren't any other
side-effects that I am aware of. Are there any?
Yes, this is an overhead, but it is small beer compared to doing a
getattr() RPC across the server room fabric to a NAS server backend.
So in summary, this is largely avoidable but unfortunately I don't think
that we can persuade the dev team to address this issue, even if I gave
them the solution as a patch :-(
Could you explain what you're talking about here?
The fact that you are engaging in this dialogue is great and I really
appreciate it. What I am still trying to work out is how to interact
with you guys in a way that is mutually productive. I did make the
mistake of choosing the mainstay stable version iN live prod systems use
-- 5.3 -- to take this whole issue apart and I guess that the dev team
regards this as history.
I guess that I should bite the bullet and switch to 5.5. I've been
working on an evaluatorfork of APC optimized for CLI/GCI which tackles a
lot of these issues head on and performs reasonable well, but I realise
that this is a dead-end and will never get deployed, but I am currently
considering regressing some of this technology into 5.5 and O+. Are you
interested in a version of O+ which supports all SAPIs?
In architectural terms I feel that having a universal cache option is
important. It changes the mindset from something which is only used in
niche performance use cases to a standard option. It also means that
the cache can be stress tested by the entire php test suite. However,
to do some of this you don't start with a patch, but with an RFC
informed by evidence, and that's my real reason for doing this demonstrator.
//Terry
