Also. the way the code works at present is that it creates anonymous functions in php, with the contents of the file, <br>and then caches those.<br><br>We got it to within 5-10% of drupal core performance, but the biggest issue was theme_link. I'm not even altogether convinced
<br>theme_link (or theme_table for that matter) should be theme functions. <br><br>ALSO.. since we are doing this to be friendly to designers, moving them all to a single .theme file is<br>still nowhere near as friendly as just 'copy this file to your theme directory to override'.
<br><br>Doing it this way means you never have to write silly phptemplate stubs again, something which<br>shouldn't have been necessary in the first place.<br><br><div><span class="gmail_quote">On 8/3/06, <b class="gmail_sendername">
Larry Garfield</b> <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, August 3, 2006 1:32 pm, Jakub Suchy said:<br>>> Adrian seems to think it is not a performance issue though.<br>><br>> Imagine you have 15 activated modules. Every module has 2 theme<br>> functions, which makes it 30 fopen() calls for every page load. This IS
<br>> performance issue.<br><br>That's assuming that you use all 30 theme functions on every page. You<br>may only use 4-5. Remember that the most frequently-used theme functions<br>are those that are already setup as separate files via the template
<br>engine: page, node, block, etc.<br><br>I'm open to suggestions on how to properly benchmark what the performance<br>difference would be here.<br><br>--Larry Garfield<br><br></blockquote></div><br>