Re: RE: yet another template

IMHO the "native caching" feature should be optional, and probably default off for compatibility. There are good reasons for using today's format (security), but it would give you an extra whooomp (would be interesting to see exactly how much) if Smarty was really able to exploit Zend Cache. And what's the speed difference between a big Perl regexp and the PHP scanner? :-) RAM usage isn't a big problem, you can limit Zend Cache's usage, buy more or whatever. Cache expiration can also be configured (ZC may or may not check the file timestamp). All of these issues are about system configuration. - Stig Monte Ohrt wrote: > > This is an intriguing idea. However, for those people not using any kind of > accelerator (such as Zend Cache), this may have a negative impact, taking more > resources since PHP would have to compile and interpret the cache files on every > click... maybe this isn't such a big deal if the majority (or all) of the cached file > is plain text? Also, I wonder how much memory a typical cached page would take up... > if you start retaining cache files in memory via Zend Cache, this could be quite > resource intensive (RAM) for potentially hundreds of pages. There are also other > things to consider such as cache expiration... (be sure Zend Cache is setup to test > the cache files each time it is executed?) > > Monte > > "Stig S. Bakken" wrote: > > > Disclaimer, just in case: the Smarty code I last read was 1.4.2, if > > you've changed this stuff since then, disregard everything I say :-) > > > > The point is that the {insert} runtime processing code reads the cache > > file into memory and does string manipulation. If Smarty simply > > processed these cache files with "include", it'd benefit from ZendCache > > (which stores byte-compiled scripts in shared memory). > > > > - Stig > > > > Monte Ohrt wrote: > > > > > > Hi Stig, > > > > > > I don't see how making the cached pages into PHP code would help with > > > performance, it would actually add an unnecessary step. The cached pages are the > > > HTML output of the page, they are not compiled or interpreted by PHP. They go > > > straight to the browser (minus a few exceptional cases like where insert tags > > > are replaced first.) Now one thing you _could_ do to gain a little performance > > > is to keep the cached content in a RAM disk to speed up I/O. For now you can do > > > that at the OS level (like using /tmp in Solaris), and I'm also working on cache > > > handling via custom functions in Smarty, which will be in the next release. This > > > way you could use something like msession so cached data (& session data) can be > > > compressed and stored on a RAM session server, and therefore can be retrieved > > > efficiently and shared in a cluster. > > > > > > Monte > > > > > > "Stig S. Bakken" wrote: > > > > > > > Andrei Zmievski wrote: > > > > > > > > > > On Wed, 07 Nov 2001, Stig S. Bakken wrote: > > > > > > Another "personal requirement" I have is that for example > > > > > > Zend Cache > > > > > > should give a performance gain for templates, basically by compiling > > > > > > templates to PHP code whose bytecode can be cached. None of the > > > > > > systems > > > > > > above currently fulfill this requirement completely, although Smarty > > > > > > is > > > > > > close. > > > > > > > > > > What do you mean with that last sentence? > > > > > > > > Smarty's cached templates are not pure PHP code. If they were, > > > > Zend(Cache|Accelerator) would give another level of performance gain. > > > > > > > > - Stig