Ideas on how to make editor checking/inspections more useful

Right now the current performance of inspections is limiting their usefulness. It takes too much time to reparse a file and if I am editing it constantly I completely loose the benefit of a smart editor catching my errors at the same time I do them (I loose my computer pair for the Pair-Programming crowd ;-).
Here are my thoughts and please feel free to shoot them down. I will file requests if people like them (and even if people don't like them anyway ;)

Have an incremental parsing/reporting: parse for compilation errors then for the custom error level then for the warning level (the builtin ones first then the third party later or have a configurable order). At any point if an inspection/syntax check returns a result report it immediately. As compilation errors are the most important they should have higher priority and run more often.
Use a junit metaphor for reporting progress and errors: Green/yellow/red bar progressively going to 100% when the file is fully parsed. Intentions can be viewed as tests. They give feedback and as usual the earlier the feedback the better.

Jacques

8 comments
Comment actions Permalink

Intentions can be viewed as tests

Obviously I meant Inspections

0
Comment actions Permalink

Another idea : add situation change flags, to help caching resuts.


b = changedLines()
b = leftIdentifier()
b = leftBlock()
b = leftMethod()
b = leftElement()


would help authors cache results when appropriat. They could decide to
not rerun an inspection if the cursor is still on the same line, in the
same block, in the same method, in the same comment.

Alain

0
Comment actions Permalink

it is true that currently error highlighting lacks
usefullness, because sometimes it is really much
quicker to recompile a file, then to wait for the
error tabs to appear.

but I'm quite sure that dramatic optimisation of
this is planned by jetbrains anyway.

regards,
Michael

0
Comment actions Permalink

should be: than to wait for the error tabs to appear.

0
Comment actions Permalink

Jacques,

what you're suggesting is very similar to way it works now.
1. We're tracking changed code blocks and do reparse them only.
2. Compilation errors are reported first then inspections are run (at this
stage an eye appears).

the only difference is we run all inspections at once. Running each of them
in a separate pass will reduce the total performance value.

And yes, I agree there's noticable highlighting performance degradation but
beleive me it has almost nothing to running inspections on the fly. We'll
work it out.

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Jacques Morel" <jacmorel@yahoo.com> wrote in message
news:20303273.1062736189811.JavaMail.itn@is.intellij.net...

Right now the current performance of inspections is limiting their

usefulness. It takes too much time to reparse a file and if I am editing it
constantly I completely loose the benefit of a smart editor catching my
errors at the same time I do them (I loose my computer pair for the
Pair-Programming crowd ;-).

Here are my thoughts and please feel free to shoot them down. I will file

requests if people like them (and even if people don't like them anyway ;)
>

Have an incremental parsing/reporting: parse for compilation errors then

for the custom error level then for the warning level (the builtin ones
first then the third party later or have a configurable order). At any point
if an inspection/syntax check returns a result report it immediately. As
compilation errors are the most important they should have higher priority
and run more often.

Use a junit metaphor for reporting progress and errors: Green/yellow/red

bar progressively going to 100% when the file is fully parsed. Intentions
can be viewed as tests. They give feedback and as usual the earlier the
feedback the better.
>

Jacques



0
Comment actions Permalink

I am also seeing a serious performance degradation in the syntax checking.

I had tried out the Inspection Gadgets using the Tools->Inspect Code.

I have not turned on any inspections in the Errors->Highlighting Options. All the InspectionGadgets Inspections say 'Do not show"

My expectation is that there should not be any impact to the automatic syntax checking, but there is a big differnce.

Without InspectionGadgets, the syntax errors show up almost instantaneously on a P4 2 Ghz laptop. With InspectionGadgets plugin added and all InspectionGadget inspections marked "Do not show", it now takes 1-3 seconds.

Unfortunately because of this, I had to uninstall the InspectionGadget plugin. Now I only install it when I want to run Tools->Inspect Code, and then I have to uninstall it afterwards.

0
Comment actions Permalink

Hmm, it surely should not behaive that way. I'll check out if your
observations are correct.
Thanks anyway.

--

Best regards,
Maxim Shafirov
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"


"Alex" <no_mail@jetbrains.com> wrote in message
news:10568052.1063157012119.JavaMail.itn@is.intellij.net...

I am also seeing a serious performance degradation in the syntax checking.

>

I had tried out the Inspection Gadgets using the Tools->Inspect Code.

>

I have not turned on any inspections in the Errors->Highlighting

Options. All the InspectionGadgets Inspections say 'Do not show"
>

My expectation is that there should not be any impact to the automatic

syntax checking, but there is a big differnce.
>

Without InspectionGadgets, the syntax errors show up almost

instantaneously on a P4 2 Ghz laptop. With InspectionGadgets plugin added
and all InspectionGadget inspections marked "Do not show", it now takes 1-3
seconds.
>

Unfortunately because of this, I had to uninstall the InspectionGadget

plugin. Now I only install it when I want to run Tools->Inspect Code, and
then I have to uninstall it afterwards.


0
Comment actions Permalink


At least as of 915, it seems to be the case that the third-party error checking doesn't seem to be taking all that long. When I test IG, I turn all of the inspections on for yellow-line error checking, and still only get half-second delays in which I "see the eye", even on largish (1000 LOC) files. This is on a non-too-beefy laptop running Windows XP.

That said, some profilings I've run indicate that there is room for improvement over the current inspections API, at least as far as batch inspections go. Currently, every time a checkClass/checkField/checkMethod is called on a IG inspection, a PSIRecursiveElementVisitor is created, which then visits each node of the parse tree, until it gets to the depth it needs to. This visitor is stateless, although it does hold a reference to the InspectionManager. This means that the work of DFS through the parse tree gets done by each inspection, but it could be shared with a more supple API (e.g., one which took PsiElementVisitors, batched them up, and did the traversal in one fell swoop). My profilings convince me that the DFS is most of the work, and that the actual checking done by IG at least an order of magnitude smaller.

As you say, this is probably not a big deal for interactive use, but it does mean that batch inspections on large projects could be improved greatly with some API changes.

Also, I'm wondering if there's not some issue with me passing you Class objects for inspections, rather than instantiated objects like the original InspectionsAPI a couple of months ago. There seems to be some load-time issues, and running Class.newInstance hasn't historically been the zippiest of operations on all JVM's. Like the visitors they create, the inspection objects are stateless, holding only context information that could be gotten at creation time.

I'm specifically not asking for this change. I'm just offering my (admittedly crude) findings and analysis.

0

Please sign in to leave a comment.