Stanislav Malyshev wrote: >> I suggest to first make the theoreticaly decision that we prefer to support >> this on a per-request if it's feasible. When I say feasible it means with >> > Per-request is very problematic with regard to bytecode caches, for > obvious reasons. However, per-virtual-dir may work for this, i.e. if > each file may have only one unicode setting then it may work.
What seems like an obvious suggestion... don't make it configurable at all at run time, in the sense that the conditionals for is-unicode will very significantly hurt performance. Why not load both PHP6 and PHP6U SAPI environments built from two different passes at the build? This ensures content configured to use the php6 traditional or php6 unicode environments behave exactly as configured. It's slightly more effort on the mass-vhoster's part to install and permit two different SAPIs (four, if they offer legacy php4/php5), but it provides for fast adoption of the uni flavor, without the performance hit against the traditional model, and without the conditionals tested on both. If you solve this at the handler/filter layer by choosing one of two (or more) different PHP engines, the resources used will actually be much less than other solutions proposed here for mass-vhosting scenarios. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
