> why oh why doesn't php/plain zend cache scripts in the first place? :-/
PHP is developed in a way that no feature is added that would harm the
performance or usability for the vast majority of people (80-90%+). Caching
would speed individual scripts, but what if you have a very large amount of
scripts or a few very large scripts? Or what if your scripts aren't used
very often and you don't have plenty of extra memory (and who does?)?
PHP's design would have to be significantly changed and altered, and many
people wouldn't use it anyway. Thus the perfect solution is just to use an
outside product. As we can see from APC and Zend Cache, caching is obviously
not very easy to accomplish. If it were, we probably wouldn't be talking
about this in the first place ;)
The only thing that needs to be changed in PHP, IMHO, is to allow
pre-compiled scripts to be handed to it for execution. Thus developing a
cache would be much easier, I'd imagine.
The way I'd think a cache would work best:
When a script is called rather than calling PHP, have it call Cache instead
of PHP directly.
The cache checks it's memory and sees if that script has been compiled. If
so it checks to ensure the source hasn't been altered since compiling it,
then it has PHP execute it and serves it out (if the page has no dynamic
pieces which change for each request like printing out the time, Cache could
just hand the page out without calling PHP).
Cache can be configured to store the most popular scripts, the one's that
are naturally the slowest, or it can be told to handle certain scripts
regardless of their popularity. And you would be able to tell it what's the
most memory it could use.
Sounds great, but if it were easy someone would have already done it.
Currently any language is only as fast as the programmer makes it. You can
write pure assembler code which trudges along at a truly embarrasingly slow
rate. PHP is no different. It doesn't matter what language you're using, the
more code that has to be run the slower it's going to be. The more librarys
you use the slower and more memory intensive the code. It's beyond reason to
think it would be any other way.
PHP is slower in code execution than the C it's written in. *pauses for the
"duuuhh!" reaction to wear off*
That's how every scripting language works, and it is completely, utterly,
and impossibly unavoidable.
Trading simplicity for speed is unavoidable, unless you want to code in
hexadecimal. PHP remains to be the best trade off between simplicity and
speed, which means that there will always be a faster language than PHP. But
IMHO, none are both faster and easier. Otherwise I wouldn't be using PHP ;)
"If you don't know why something isn't working, it's probably your fault."
(words to live by :)
Plutarck
"Steven Haryanto" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> yes, i have discovered recently that php is not as fast as it
> is hyped to be. don't get me wrong. php is fast, but it depends
> on how you arrange your scripts. if you include a lot of library
> code (PEAR, etc etc), the overhead would increase and increase.
> i thought php has always cached compiled scripts (since it is
> fast enough for me so far), but the fact is it does not. without
> cacher like apc or zend cache, mod_php is no better than cgi,
> except it avoids per-request forking and configuration parsing.
>
> why oh why doesn't php/plain zend cache scripts in the first
> place? :-/
>
> Regards,
> Steve
>
> On 20/05/2001 20:53, Christopher Leigh wrote:
> >ok, are servlets/jsp faster than php4?
> >since zend cache isn't free... :(
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
