Some ideas about performance

Most of this is probably just not worth it, but it'd be interested in actually getting any numbers for it. Rule number one in optimization is still "Don't guess, but measure".

EDIT: Disregard the list items about PageTemplates, probably the effort isn't worth it. Instead looking into NKOTB might be worthwile.

• Use lazy attribute access (like in request.locale) on the globals views. This is tricky, as the the attributes are set as globals into the tal engine. With some evil hacking we might still be able to do it and it could make for an incredible performance gain (think classic portlets calling global_defines).
• Remove admin-ui stuff from public interface, does this make a huge difference? Add it as a second layer / skin instead?
• Use some plain-text html instead of actions for some parts of the public ui (site_actions : sitemap, accessibility, contact, site setup) -> viewlets (portal_tabs : home) -> simple on/off property switch (document_actions: rss, sendto, print, fullscreen, extedit) -> viewlets
• Cache locally allowed types (see FasterPlone by astonor, or patch by alecm for CMF). Maybe cache on containerish instances with an invalidating event subscriber for IObjectModifiedEvent on ITypesTool and the instance itself (for the local restrict stuff)?
  
• Add a CacheChooser utility which supports a blacklist and has a controlpanel, so people can turn of caching for a particular customized template/viewlet. Should still be able to make using memcached instead of zope.ramcache easy.
• Cache more viewlets with their default dependencies, after we have a cache chooser you can turn caching off for the customized ones. Maybe we could even automate this (hook into plone.app.customerize) with an event?
• Adapt or extend actions / categories to ICachableAction / Category, which adds one more Expression to them, which is used as a cache key in a plone.memoize.ram cache. Ideally we would only need to calculate one or two keys per category and not all the icon, url and available expressions for each action.
• Look into adding a general configuration changed event, which is fired by the control panels and invalidates the ramcache through a subscriber. Do we need more than one ramcache then or only invalidate cache entries beginning with a certain prefix / namespace? As a start invalidating everything might be ok.
• Add a product installed / uninstalled / upgraded event and invalidate the cache as well. Maybe an objectmodified event on IQuickInstallerTool works already.
• Look into the PyPy work from __gotcha on tal.
• Look into PushPage by tseaver. Is taking away the context crap from PT's making those any faster?
• Can we make a second SimplePageTemplateFile implementation that takes away macros and the context except for the one delivered by the view. Does using such a thing makes it any faster? Customizing this should still give you a full PageTemplateFile. It should have a FS* variant and a special file extension, so it can be used for CMF skin based templates.
• Do PT's support any kind of stored/cached (partial) compilation? Same question for Python scripts? Can those without any conditions and loops be turned into simple Python string variable substitutions? '<a href="%s">%s</a>' % (var1, var2) Is this doable in a safe way and actually faster for simple templates? How does this work in regard to i18n; explicit translate calls?
• Is using Python expressions faster than Path expressions or the other way around? Does this change for builtins vs. complex objects? Does it make a difference to make things available in local namespaces? 'tal:define="foo foo"' in loops?
• Is contentprovider lookup reasonably fast or is there something that can be cached in there? Is this actually faster than macro inclusion?
• Add an in-memory (proxy) cache for the portal_properties/types_tool whatever is queried in a normal page rendering often. Does avoiding ZODB reads speeds up anything here?
• The catalog should move to its own ZODB file with a high number of cached objects (default: around 50-100megs, how many objects is that?). How can we automate this / make this easier?
• Benchmark object creation. What's the actual bottlenecks in there?
• Does portal_factory use a temporary storage already? Is this really fast or could it be made faster?