You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (Created) (JIRA)" <ji...@apache.org> on 2012/02/15 15:34:59 UTC
[jira] [Created] (CAY-1667) Expression parser performance
optimization
Expression parser performance optimization
------------------------------------------
Key: CAY-1667
URL: https://issues.apache.org/jira/browse/CAY-1667
Project: Cayenne
Issue Type: Improvement
Components: Core Library
Affects Versions: 3.1M3
Reporter: Andrus Adamchik
Assignee: Andrus Adamchik
Inspecting some profiling data from a customer I see an inefficiency inside Expression.fromString. It was actually discovered inside Ordering class, that compiles path string on demand, so it affects even the queries that do not use 'fromString', as well Orderings created for in-memory sorting. There are 2 culprits in JavaCharStream that is generated by javaCC (although JavaCharStream is not a part of the parser, so we can probaby change the code on top of the generated class) :
1. JavaCharStream.fillBuff() has throw new java.io.IOException(); that is caught right in that same method (!!!) Throwable.fillStackTrace() shows as a "hot spot" in the profile. There should be a better way to handle if/else condition :)
2. Expression.fromString -> new ExpressionParser(Reader) -> new JavaCharStream(Reader, int startline, int startcolumn)
JavaCharStream constructor is heavy and shows as a hotspot. For one thing it creates 4 int/char buffers with size of 4096 each. I don't think we have such long expressions ever, and don't need all this memory. Moreover we can probably guess the max needed buffer size from the original String length. My guess is that most expressions are under 100-300 chars. Certainly true for the orderings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAY-1667) Expression parser performance
optimization
Posted by "Andrus Adamchik (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrus Adamchik closed CAY-1667.
--------------------------------
Resolution: Fixed
Fix Version/s: 3.1M4
> Expression parser performance optimization
> ------------------------------------------
>
> Key: CAY-1667
> URL: https://issues.apache.org/jira/browse/CAY-1667
> Project: Cayenne
> Issue Type: Improvement
> Components: Core Library
> Affects Versions: 3.1M3
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Fix For: 3.1M4
>
>
> Inspecting some profiling data from a customer I see an inefficiency inside Expression.fromString. It was actually discovered inside Ordering class, that compiles path string on demand, so it affects even the queries that do not use 'fromString', as well Orderings created for in-memory sorting. There are 2 culprits in JavaCharStream that is generated by javaCC (although JavaCharStream is not a part of the parser, so we can probaby change the code on top of the generated class) :
> 1. JavaCharStream.fillBuff() has throw new java.io.IOException(); that is caught right in that same method (!!!) Throwable.fillStackTrace() shows as a "hot spot" in the profile. There should be a better way to handle if/else condition :)
> 2. Expression.fromString -> new ExpressionParser(Reader) -> new JavaCharStream(Reader, int startline, int startcolumn)
> JavaCharStream constructor is heavy and shows as a hotspot. For one thing it creates 4 int/char buffers with size of 4096 each. I don't think we have such long expressions ever, and don't need all this memory. Moreover we can probably guess the max needed buffer size from the original String length. My guess is that most expressions are under 100-300 chars. Certainly true for the orderings.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAY-1667) Expression parser performance
optimization
Posted by "Andrus Adamchik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAY-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208508#comment-13208508 ]
Andrus Adamchik commented on CAY-1667:
--------------------------------------
Talking of orderings, since expression is always a property path, do we even care to do a full parse? We can probably just check whether this is DB or Obj path, and instantiate an approprate ASTXyzPath.
> Expression parser performance optimization
> ------------------------------------------
>
> Key: CAY-1667
> URL: https://issues.apache.org/jira/browse/CAY-1667
> Project: Cayenne
> Issue Type: Improvement
> Components: Core Library
> Affects Versions: 3.1M3
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
>
> Inspecting some profiling data from a customer I see an inefficiency inside Expression.fromString. It was actually discovered inside Ordering class, that compiles path string on demand, so it affects even the queries that do not use 'fromString', as well Orderings created for in-memory sorting. There are 2 culprits in JavaCharStream that is generated by javaCC (although JavaCharStream is not a part of the parser, so we can probaby change the code on top of the generated class) :
> 1. JavaCharStream.fillBuff() has throw new java.io.IOException(); that is caught right in that same method (!!!) Throwable.fillStackTrace() shows as a "hot spot" in the profile. There should be a better way to handle if/else condition :)
> 2. Expression.fromString -> new ExpressionParser(Reader) -> new JavaCharStream(Reader, int startline, int startcolumn)
> JavaCharStream constructor is heavy and shows as a hotspot. For one thing it creates 4 int/char buffers with size of 4096 each. I don't think we have such long expressions ever, and don't need all this memory. Moreover we can probably guess the max needed buffer size from the original String length. My guess is that most expressions are under 100-300 chars. Certainly true for the orderings.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira