Re: Some more plane hacking...

Rasmus Lerdorf wrote: > > Yes, I thought there would be some anti-C sentiment like this here, which > is basically why I sent the probe out just to see how much there was. Really hate to be the only evil voice :-) > That doesn't change the fact that PHP is not just for users that host > their pages with ISPs. It is also for people who build large sites on > servers they have full control over. I maintain many servers and have found that PHP is for me :-) > Have a look at the numbers. Take this example class: > [..] > For something that is as intrinsic to a large site as a templating system, > a 25% speed increase just on property initialization is significant. And > this is before any of the methods have been converted which is where the > real performance benefit is likely to be seen. Real sever page optimizations are minimizing the numbers of access to disc. Ram, no external js, no external css, reduced number/size of images, etc. > The added benefits in an ISP situation is also obvious. In this case > Smarty configuration settings could be set on a per-virtualhost basis and > the astute ISP could sell this as a service. So the best way is converting scripts to C? Why not optimize the engine and benefit all the srcipts? Or provide a "C whatever" to initialize properties faster and make them avaible thru php.ini? Also a user-land solution is to use a cached pre-compiled scripts tool. > > > Let's define "professional". I have one server with 1,5 millon _hits_ a > > day with php, templates, postgres, and it's running fast and smooth. The > > amount of speed you can gain optimizing classes is nothing compared to > > optimizing queries, databse, SO, web server. > > If we are talking of > 50.000 visitors a day you're not talking in > > "general purpose" terms (isn't PEAR a "general purpose > > repository"?). > > I would certainly hope that anything written using a lot of PEAR > components could handle much more than 50.000 visitors per day. That's > less than 1 request per second. Whenever I am building something I try to > make sure I go no lower than 50 requests/sec on the main pages of the > site. And my low watermark for a complete rethink/rewrite is at around 12 > requests/sec. 12 request/sec translates to about 1 million hits per day. You are talking about 1 million "pages views" (php hits) per day? I red sometime ago the Microsoft site gets this amount of traffic per day. The solution here is build static html pages generated from a dynamic site, if you want a really faster site (note: this will be a cool contribution to PEAR). Don't you think so? You can not compare the amount of Pear users who preffers usability against the amount of users who really needs what you're talking about. But having those optimization choices is great, (I'll probably use some of them in specific cases), only don't agree on having them as the only choice. Just trying to defend "normal" Pear users. > > Just ask a question if you let me: the guys who are promoting C > > extension will join to pear and work in the this C extensions? will > > maintain them? will ensure cross-platform/cross-compiler ability? will > > attend bug reports? > > There is no guarantee of that, just like there is no guarantee for that in > userspace-PEAR stuff. No posible comparation here. Maintain/enhance PHP Pear stuff is a task that every of us could do. > The C API hides most of the cross-platform issues, > just like the PHP scripting language itself does. But there will still be > issues, both in script-space and in C-space that could affect things > across different platforms. > The main cross-platform issue we have in PEAR is the DIRECTORY_SEPARATOR. It's the same in C? Tomas V.V.Cox