Retrieving editor caret position during LocalInspectionTool execution
Answered
Hi,
I'm creating an inspection for a JavaScript based test automation solution. There are screenshot/image based assertions in each test file, supplied at each location with the name of the screenshot to assert/create. Since the test framework doesn't allow having the same screenshot name multiple times specified in the same file, what I'm checking (via JSElementVisitor#visitJSFile()) is that there is no more than one assertion referencing the same name.
Now, in case of really long test files, traversing the whole PSI file at each edit, to check each assertion can be expensive, so what I have in mind is to:
- check the location of the caret in the current editor,
- if it is located at a string literal, it probably means that the last edit happened on (or around) a string literal. If it wasn't a string literal edited, LocalInspectionTool#buildVisitor() would return an empty visitor. This aims to lessen the number of times the PSI file structure is traversed, because the logic would run only when the edit potentially happened at a location we care about.
The questions I have:
- Is it a good approach to involve caret position checking during an inspection execution in general, and also given that file editors are available from EDT with IW lock only (see com.intellij.openapi.application.impl.ApplicationImpl#assertIsDispatchThread())?
- Regardless it's a good approach or not, do you think it would provide an at least somewhat significant performance gain?
- Do you see any alternate ways/methods with what such an inspection could be optimized?
Or maybe I'm just overthinking it?! :)
Thank you!
Please sign in to leave a comment.
Changes in document can occur from many places: some refactoring, VCS update, etc.
Please perform some actual performance measurements that highlight clearly the hot spots, then share code and then we could suggest ways on how to improve. Some general recommendations are given here https://plugins.jetbrains.com/docs/intellij/performance.html
That's a good point regarding changes, and I will look into some performance testing to see the actual performance of my code.
Thank you.