incubator-adffaces-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer (JIRA)" <adffaces-iss...@incubator.apache.org>
Subject [jira] Resolved: (ADFFACES-394) Style sheet processing optimization
Date Tue, 17 Apr 2007 00:11:15 GMT

     [ https://issues.apache.org/jira/browse/ADFFACES-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Winer resolved ADFFACES-394.
---------------------------------

    Resolution: Fixed

Fixed. Processing the Trinidad minimal stylesheet is now about 93% faster (50ms -> 3.6ms).
 On a much larger stylesheet, timings improved from 440ms to 10ms (97.5% improvement).  The
problem listed in the bug report was half (or, rather 2/3) of the problem - there was a second
O(N^2) algorithm in the stylesheet codebase.


> Style sheet processing optimization
> -----------------------------------
>
>                 Key: ADFFACES-394
>                 URL: https://issues.apache.org/jira/browse/ADFFACES-394
>             Project: MyFaces ADF-Faces
>          Issue Type: Improvement
>          Components: Skinning
>    Affects Versions: 1.0.1-incubating-core-SNAPSHOT
>         Environment: Windows XP
>            Reporter: Andy Schwartz
>         Assigned To: Adam Winer
>            Priority: Minor
>
> While investigating performance of initial page delivery I noticed that on the very first
page delivery a large percentage of the time is spent in style sheet processing code.  In
particular, a bit of profiling reveals that StyleSheetDocument.getStyles() - specifically
the calls to _resolveStyle() - can be expensive.  On a slower machine with a large custom
stylesheet this can add up to several seconds.  Interestingly, this particular performance
problem is self-documenting...  The following comment taken from StyleSheetDocument.java:
>     // Now, loop through all StyleNodes in all StyleSheetNodes
>     // Note: The algorithm used here is actually much more inefficient
>     // than it needs to be.  We're using a n-squared algorithm here -
>     // for every style we find, we need to loop through all other styles.
>     // The reason for this is because this allows us to share code
>     // (namely _resolveStyle()) with getStyleBySelector/Name().  However,
>     // we could probably double the performance of CSS generation by
>     // optimizing this routine to make a single pass through all styles,
>     // and then resolve everything in one step.  
> Leaving aside questions about whether "doubling" the performance would be the actual
result :-)  , the idea is that this would work as follows:
> - First pass built up a mappings from selector/name to a list of matching StyleNodes.
> - The second pass then resolves the styles based on the mappings created in the first
pass.
> This should avoid the current n-squared behavior and presumably reduce the amount of
time spent in this code, thus speeding up initial page delivery.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message