Loading ...
Sorry, an error occurred while loading the content.

[Cheetahtemplate-discuss] Re: Import speed issue

Expand Messages
  • Dave Kirby
    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
    Message 1 of 2 , Oct 31, 2003
    • 0 Attachment
      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
    • Tavis Rudd
      Hi Dave, both of these wishes are on my wishlist for the next-gen of Cheetah, though for other reasons. Cheers, Tavis ... This SF.net email is sponsored by:
      Message 2 of 2 , Oct 31, 2003
      • 0 Attachment
        Hi Dave,
        both of these wishes are on my wishlist for the next-gen of Cheetah, though
        for other reasons.
        Cheers,
        Tavis

        On Friday 31 October 2003 09:47, Dave Kirby wrote:
        > 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



        -------------------------------------------------------
        This SF.net email is sponsored by: SF.net Giveback Program.
        Does SourceForge.net help you be more productive? Does it
        help you create better code? SHARE THE LOVE, and help us help
        YOU! Click Here: http://sourceforge.net/donate/
        _______________________________________________
        Cheetahtemplate-discuss mailing list
        Cheetahtemplate-discuss@...
        https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
      Your message has been successfully submitted and would be delivered to recipients shortly.