656: Tempcode optimiser - Composr CMS feature tracker

ID	Project	Category	View Status	Date Submitted	Last Update

656	Composr	core	public	2012-07-02 18:03	2013-09-29 20:34

Reporter	Chris Graham	Assigned To	Chris Graham
Priority	normal	Severity	feature
Status	resolved	Resolution	fixed

Summary	656: Tempcode optimiser
Description	The challenge is to move Tempcode output as close to echo'ing a static string as possible. This is split into a number of rings: Ring -2, Ring -1, Ring 0, Ring 1, Ring 2, Ring 3. Different steps are performed in different rings, because they work off of each other. Probably in actual implementation each step will be defined in a method and there might just be one loop that keeps running each method again and again until there is nothing left to bubble out. For all this to work we will need to be able to convert between our two internal Tempcode representations (runtime and compiled). That will be tricky, as compiled provides no meta data (and it can't, for performance) so we will need to be able to parse the compiled code back into runtime code. INITIAL COMPILATION... Optimise out some Tempcode variables (Ring 0): 1) Ones that align perfectly with standard caching parameters, like '{$THEME}' or '{$LANG}'. 2) Ones that are only dynamic in the sense that the Admin might edit something. All language variables count here (e.g. '{!FOO}'). Also config options. Also theme images. We just make sure that when the admins edits, a full Tempcode cache flush happens. INITIAL COMPILATION/SERIALISATION... Do a multi-pass sweet to optimise out static expressions, replacing with literals (Ring 1). For example, "{$EQ,x,y}" will always be be "0" (false). We'll have static expressions due to the variable optimising out or due to parameters passed in prior to block cache serialisation. Unroll IF/IF_EMPTY/IF_NON_EMPTY directives that rely on literals (Ring 2). We'll have literals due to the optimising out of static expressions. SERIALISATION... Unroll IF_EMPTY/IF_NON_EMPTY directives that rely on parameters (Ring -2). Embed escapings (Ring -1). If a parameter is always escaped in the same way (disregarding usage in IF_EMPTY,IF_NON_EMPTY) then the escapings can be compiled directly into the bound parameter value. Inline the parameters (Ring -1). Parameters bound into the Tempcode can be inlined. Only do this for parameters that are only used once, or are very simply literals (i.e. no more bytes than the number of bytes used to link them in). If parameters are used zero times, discard them. If no 'keep_' parameters are in the URL, evaluate any 'KEEP' and 'PAGE_LINK' symbols (Ring 0). For this to be valid, our block cache signature generator must auto-inject a "has keep_ parameters in the URL" signature component. If now 100% static store as plain-text, not Tempcode at all (Ring 3). The to_assembly method will return a special value indicating that it should be stored as plain-text. As a have-we-done-well check after optimisations are finished we can look at the block cache and expect most things to be stored as plain-text, not Tempcode.
Additional Information	Success metrics (not guaranteed, but nice targets to check to after work is done, to avoid stopping short): - The main_news block caches as plain-text - Overall output makes Composr faster than Wordpress, for a page set up with the same features as Wordpress's default install + 10 Lorem Ipsum posts - If we're not, we need to look at why -- and if features can be turned off so we DO match (Composr must be able to strip down...)
Tags	Type: Performance
Attach Tags	(Separate by ",")

Time estimation (hours)	22
Sponsorship open

Date Added	Member	Amount Sponsored

Chris Graham 2013-09-29 20:34 administrator ~1796	This is kinda implemented. A lot written here isn't really workable, because the bulk of Tempcode evaluation actually runs on shared functions that come from templates. We can't change/inline that, as it would use additional RAM in a very poor trade-off. Never-the-less, many ideas from this are now implemented (mainly in the compilation stage, with added idea of automatically replacing some symbols with PHP operators) and it actually seems to have given a 15% performance gain. This is working well alongside other Tempcode optimisations, and as discussed, we are very effectively making it so that Composr architectural features either optimise away, or don't have any cost if chosen to be disabled.