Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

【Question】Should the results of Expression#RESOLVE cache? #4379

Open
RTxin opened this issue Apr 19, 2024 · 1 comment
Open

【Question】Should the results of Expression#RESOLVE cache? #4379

RTxin opened this issue Apr 19, 2024 · 1 comment
Labels
Question (AST) Questions about nodes and relationships within the AST (not about how to use JavaParser)

Comments

@RTxin
Copy link

RTxin commented Apr 19, 2024

  1. If I write multiple rule detectors that use 'resolve' or calculateResolvedType, since the current resolve is re-executed each time, I consider JP can exchanging some space for time to reduce the time cost of resolve。
@RTxin RTxin changed the title 【Question】Expression#resolve的结果是否应该缓存? 【Question】Should the results of Expression#RESOLVE cache? Apr 19, 2024
@jlerbsc jlerbsc added the Question (AST) Questions about nodes and relationships within the AST (not about how to use JavaParser) label Apr 19, 2024
@jlerbsc
Copy link
Collaborator

jlerbsc commented Apr 19, 2024

Javaparser already has a cache to prevent certain costly operations from being re-executed. You can also add caching to your own code if you wish, but if you propose a modification to JP you will have to demonstrate that your solution has real added value.

To answer your question more precisely, it is indeed possible that caching the result of this method could be valuable. I also occasionally work on this subject but for the moment I haven't validated the solution I've implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question (AST) Questions about nodes and relationships within the AST (not about how to use JavaParser)
Projects
None yet
Development

No branches or pull requests

2 participants