I also have issues with the time taken to import Cheetah.Template - on my
1.7 GHz XP machine, it can take up to 3 seconds for that single import.
This is not an issue for those using long-running processes such as
Webware, but if you are constrained to using CGI then it is a serious problem.
I have not studied the source in any depth, but it looks like it is
importing everything you need to compile templates and generate the Python
code. If you are using pre-compiled templates this is unnecessary baggage.
Would it be feasable to split out the code needed to run the generated
python into a base class of Template, and derive the compiled Python class
from that? This would allow precompiled templates to be loaded much more
quickly.
A further 'nice to have' optimisation would be to be able to specify at
compile time that you are not using filters, Webware transactions etc, and
not generate code that uses them. This would remove the need to import
DummyTransaction and the Filters module.
Dave Kirby
| 