Re: Some more plane hacking...

> 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. Well, like I said initially, big chunks of code would probably remain in PHP space and all the things you mention would help speed up that part on top of whatever gains there are. > 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? ErrorDocument 404 /cache.php ::cache.php:: <?php $s = $REDIRECT_ERROR_NOTES; $d = $DOCUMENT_ROOT; // determine requested uri $uri = substr($s, strpos($s,$d) + strlen($d) + 1); ob_start(); // Start buffering output // ... code to fetch and output content from DB ... $data = ob_get_contents(); // ... logic to determine if data should be cached // and whether dirs need to be created $fp = fopen("$DOCUMENT_ROOT/$uri",\'w\'); fputs($fp,$data); fclose($fp); ob_end_flush(); // Flush and turn off buffering ?> voila, static pages generated dynamically. Variation on an old idea Stig had. Refresh your cache simply by deleting your static files... > > 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? For the most part, yes. Every common thing has been abstracted. -Rasmus