You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-issues@incubator.apache.org by "Andy Schwartz (JIRA)" <ad...@incubator.apache.org> on 2007/03/02 23:26:51 UTC
[jira] Created: (ADFFACES-394) Style sheet processing optimization
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: 2.0.0-incubating-core-SNAPSHOT, 1.0.0-incubating-core-SNAPSHOT
Environment: Windows XP
Reporter: Andy Schwartz
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.
[jira] Assigned: (ADFFACES-394) Style sheet processing optimization
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Winer reassigned ADFFACES-394:
-----------------------------------
Assignee: Adam Winer
> 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.
[jira] Resolved: (ADFFACES-394) Style sheet processing optimization
Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
[ 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.
[jira] Updated: (ADFFACES-394) Style sheet processing optimization
Posted by "Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/ADFFACES-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Weßendorf updated ADFFACES-394:
----------------------------------------
Affects Version/s: (was: 2.0.0-incubating-core-SNAPSHOT)
(was: 1.0.0-incubating-core)
1.0.1-incubating-core-SNAPSHOT
> 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
> 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.