[Laszlo-dev] [Platform-team] css performance

[Pablo Kang]

On Fri, 5 Sep 2008, Max Carlson wrote:

> Moving to laszlo-dev:
>
> P T Withington wrote:
>> 2 comments:
>> 
>> 1) That's an awful lot like our original approach that Pablo did, which 
>> eventually proved unsatisfactory, so we replaced it with 'real' CSS.
>
> Pablo, do you remember what was unsatisfactory about compile time-CSS? I 
> suspect it had to do with applying CSS values based on placement, which can't 
> be determined from the LZX.



Yes, part of it was placement. The other was that you couldn't apply 
compile-time CSS on classes that were instantiated programmatically.

Programmatic instantiation happens only in a few places in the app. 
My guess is that most styles can be applied at compile time without issues.




> Right now we don't do 'real' CSS because a) you have to explicitly call out 
> the attributes ($style) that CSS applies to, and b) you can't change CSS 
> properties/stylesheets at runtime, only init/compile time.
>
> Long term, I want to address a) and b). Here's a proposal:
>
> For a) we start up the app and apply the stylesheet(s) to every attribute of 
> every node, tracking the attributes/classes that change. Next, we serialize 
> the result.  Finally, the compiler adds any missing $style declarations to 
> the LZX class declarations.  Developers can still apply explicit $style 
> declarations.
>
> b) requires a move to a model where stylesheets send mutation
> events.  Nodes would subscribe for event(s) so they'd know when to re-apply 
> their values.  This could be a course-grained event sent when any attribute 
> in the stylesheet changes.
>
>> 2) That's a whole lot of work that would be very hard to have done in time 
>> to help WT's next release.
>> 
>> How about I try my simple idea for a day or two and see a) if it works, and 
>> b) what it buys us?
>
> Agreed, I was thinking of it as a long-term plan.  Any improvements to the 
> runtime processor will be welcome!
>
> I'm going to see what I can do to make the runtime CSS cache persist across 
> app invocations.
>
>> On 2008-09-05, at 11:36EDT, Max Carlson wrote:
>> 
>>> There's another approach David and I hatched at lunch yesterday.  The only 
>>> way I believe we're going to see a significant speedup is by using a 
>>> different approach.  I propose we apply the CSS on the server at compile 
>>> time.  Later, we can look at which attributes and automatically annotate 
>>> them with $style constraints, so developers don't have to deal with this.
>>> 
>>> This approach won't work for nodes that are placed at runtime, but it will 
>>> help by moving the majority of the CSS processing from startup to compile 
>>> time.
>>> 
>>> Sarah Allen wrote:
>>>> This sound like a good approach technically (given what little I know 
>>>> about css).  Amy and I will work out with the rest of the management team 
>>>> when we can schedule this work :)
>>>> P T Withington wrote:
>>>>> The function is relatively huge, because Max has already inlined a lot 
>>>>> of its dependent functions inside of it.  But the function is memo-ized, 
>>>>> so the cache already exists; perhaps the cache-check should be inlined 
>>>>> at the (single) call site.  What is unclear is how often the cache is 
>>>>> hit and how often the function has to do things the hard way.
>>>>> 
>>>>> Here's an optimization idea:  Right now, we are filling the property 
>>>>> cache lazily -- we only cache properties that we look up. _And_ we are 
>>>>> only filling the property cache locally -- we only cache properties that 
>>>>> are defined by rules that apply locally, we are not caching inherited 
>>>>> properties.  We could do a few things:
>>>>> 
>>>>> 1) When a node property cache is empty, if the immediate parent already 
>>>>> has a property cache, initialize the node property cache to a copy of 
>>>>> the parent property cache (we're going to look there anyways).
>>>>> 
>>>>> 2) When we have to compute the rules and specificity, instead of just 
>>>>> looking up the one property we have been asked for, cache all the 
>>>>> properties that the rules define.
>>>>> 
>>>>> That should make it so only the first call to getPropertyValueFor ever 
>>>>> has to do any work.  It should make it so that it never has to recurse 
>>>>> up the parent chain more than once (if the parent has a property cache, 
>>>>> you know it is complete).  It should also make it trivial to in-line the 
>>>>> cache check at the call site.
>
> -- 
> Regards,
> Max Carlson
> OpenLaszlo.org
>