Re: performance and parseFile()
Brandon Long <[email protected]> Wed, 19 Aug 2009 12:34:43 -0700
| Newsgroups | gmane.text.clearsilver.general |
|---|---|
| Organization | Fiction L Networks |
| Message-ID | <20090819193443.GA15211@bl1> |
On 08/19/09 Ogla Sungutay uttered the following other thing: > Hi guys, > > Before calling render(), do we always have to parseFile()? > I'm experimenting with FastCGI, and I thought I could store the parsed > templates (one call) and then just render the parsed tree with new HDF > over and over again. Yes, you definitely can. That said, there's a couple gotcha's you need to watch out for. Basically, anything that uses an HDF during parse needs to have the same HDF value during every render. The two places where CS uses HDF during parse is include and evar. Include can either just point at a variable (less likely) or include a file which is found by the hdf.loadpaths set of paths. You can replace include with linclude, but that will cause the file to be parsed at render time, which is probably not what you want. One thing we sometimes do, if we're using variable hdf.loadpaths, is to cache a parse for each hdf.loadpaths setting. Evar obviously uses the variable directly. You should be able to replace it with an lvar easily, the size of the evar is usually pretty small, so parsing it shouldn't be that expensive. If you don't change hdf.loadpaths, you don't use evar, and your includes all use static strings, then everything's good. I've debated putting in a mode where we'd cache parsed CS files and variables, so things would just work even with include/evar, but everyone who's needed that extra performance has been able to work around the above limitations and make it work. Brandon -- "Well, my logic is that if a killer asteroid obliterates the earth, causing tidal waves and cosmic fires that destroy every submicroscopic trace of life on this planet as we know it, and I still owe three grand on my Visa, I win." -- Dennis Miller 3/16/2001