Re: [PHP] ok, are servlets/jsp faster than php4?

2001-05-21 Thread Plutarck

 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]




[PHP] ok, are servlets/jsp faster than php4?

2001-05-20 Thread Christopher Leigh

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]




Re: [PHP] ok, are servlets/jsp faster than php4?

2001-05-20 Thread John Lim

Well if you had more RAM and a faster CPU, servlets/jsp would be faster :-)

This link might not answer your question completely, but it could help...

http://php.weblogs.com/jsp

Christopher Leigh [EMAIL PROTECTED] wrote in message
000701c0e134$4223b800$01eea8c0@contrec">news:000701c0e134$4223b800$01eea8c0@contrec...
 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]




Re: [PHP] ok, are servlets/jsp faster than php4?

2001-05-20 Thread Steven Haryanto

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]