Performance: re-parsing pre-compiled templates

[Jorge Ortiz]

I was benchmarking the performance of some scalate/ssp code I'm running, and noticed that a lot of time was being spent re-parsing templates that had already been pre-compiled.

I traced the parsing down to the following lines in TemplateEngine's loadPrecompiledEntry method:

      // Even though the template was pre-compiled, it may go or is stale

      // We still need to parse the template to figure out it's dependencies..

      val code = generateScala(source, extraBindings);

      val entry = CacheEntry(template, code.dependencies, lastModified(template.getClass))

The call to generateScala was triggering the parsing, and it's output was only being used to call `code.dependencies`. However, all the instantiations of the Code class define dependencies to be just Set(source.uri).

I removed the call to generateScala and replaced `code.dependencies` with just `Set(source.uri)` and everything still seems to work fine (with a nice performance boost if the code has been pre-compiled).

Digging through the git history, it looks like ssps used to have more complicated dependencies, but that code went away when "<%@ include ..." went away.

Is this a reasonable change to make? Should I submit a pull request?

--j

[Rafał Krzewski]

I don't know this code but something's fishy here. Re-parsing template at runtime does not sound like a good idea, it probably would be better if the dependency information was stored inside the class file as a static field or something  and then was accessed reflectively when needed.

On the other hand assuming code.dependencies = Set(source.uri) sounds like dependency information is not available / used at all! I imagine that it could cause annoying problems in development mode (applications that modify their own templates at runtime are pretty rare :))

I'd suggest more thorough examination how this dependency tracking is supposed to work / how it works at present before merging this particular PR.

Cheers,
Rafał