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