Re: Function caching...

Ron Chmara wrote: > > Kristian Koehntopp wrote: > > Jacob Verhoeks wrote: > > > The performance problem is not with executing but with the loading of the > > > code. We are currently developing a application server in php. That will be > > > loaded only once. > > The current performance limitations in PHP come from multiple > > design limitations. > > Keep in mind that some limitations are apache, some are the web, some > are PHP. > > > Another problem is the setup time for large data structures, for > > example a large network of objects representing an entity > > relationship model by proxy or similar abstraction layers. > > PHP is absolutely, positively, the wrong place to do this. Ron, this is an old discussions. Some think of PHP as the BASIC of the Web, some such as Kristian and me would like to have a little more difficult but also more performant language: (stronger) typed, improved OO features, ... WebObjects for example offers an ER model proxy and it gets used on many high load sites. If we could rebuild such a proxy in PHP, we could switch the underlying storage container of our applications without code changes e.g. from LDAP to MySQL to Oci8. You can't do so with the help of the PHPLib or PEAR database abstractions. The possibility to switch the storage container requires a proxy. Do we need this? Yes. We already wrote a simple table proxy for MySQL and LDAP. More and more of our major customers use it. > If you want speed, abstractions are the wrong approach to take. > Scripting languages, creating abstractions, to serve over web > pages?... ouch. Write it in C, not as objects in PHP. Why is PIKE, the scripting language of the Roxen Webserver, faster than PHP 4. It's not only 10, 20 or 30% faster. It does not make sense to write a C extension for everything. If you would do so, you would need trained C programmers not only scripters. And extension introduce the need to recompile and install a new PHP interpreter with every new version of your extension. This is far more complicated than simply replacing some php library scripts. > Quite simply, designing applications for the web is completely > *unrelated* to design principles for desktop applications. > If you are trying to combine the two, you'll likely wind > up with the ASP problem: Unweildy workarounds to simulate > the design of a desktop application. On a desktop, where > it's considered OK to use 100% of the CPU for a program load, > your object overhead will be less costly to the user. But > on a server, with multiple users, you need to either massively > power the server, or change the design philosophy. On a Every complex application needs some underlying library code. All large systems I have heard of use lots of helper functions (DB abstraction, Sessions, Permissions, lots of HTML widgets, ...). Pentap (Till Gerken, Tobias Ratschiller, Sterling Hughes,...) is even talking about "PentOS". Whatever that term means, it's not going to be something small. Of course reundant code is faster, but it's hard to change anything afterwards. Without abstractions you mostly end up rewriting large parts of your applications. Development time will be longer. PHP has to face the situation that our applications became bigger and bigger over the years. Most commercial content manangement systems or B2B applications have a size of 40 - 100k loc (PHP code, no HTML). Would you wan't to write such applications without abstractions? None of them is using an ER modell abstraction on the pages that serve articles or database reports because it's to slow. But most of them use HTML widgets to allow easy customization and even these abstractions are too slow it they do something more than print_table_head() etc. Ulf