Build 957 Performance

I think it is really obvious that Build 957 feels much slower than even
the last build. For instance, it takes over two and a half minutes just
to bring up IDEA--once everything is parsed and such.

When I make a change to a file, it takes about 10 seconds or more to highlight
all the errors introduced. For example, if I remove a class field I want to
find all the places it was used. Before, it seemed almost instantaneous. At
least I saw the results in roughly 2 seconds or less.

My guess is that JetBrains introduced a butt-load of assertions into the code,
because the issues I had on startup were assertion failures. The weight of all
the error checking seems to be really noticeable.

Now, to see if my guess is correct, how do we customize the startup command line
to turn off assertion checking? It would be really interesting to see how much
of an effect it is having. If there is no perceived change in performance, then
IDEA has a lot of profiling to do before GM.

21 comments

Berin Loritsch <bloritsch@d-haven.org> wrote:

That's weird... I haven't gotten more than a glimpse yet but for me it
seems considerably faster (typing doesn't lack behind anymore). But that
has to be investigated further in the next couple of days ;)

Now, to see if my guess is correct, how do we customize the startup
command line to turn off assertion checking? It would be really
interesting to see how much of an effect it is having. If there is no
perceived change in performance, then IDEA has a lot of profiling to do
before GM.


AFAIK assertions are turned off by default for Java applications unless
the programmer explicitely enables them. They are not enabled from the
command line but they are probably enabled from within IDEA via
setDefaultAssertionStatus(boolean). Therefore playing with the command
line options might have no impact.

Dirk Dittert

0

Dirk Dittert wrote:

Berin Loritsch <bloritsch@d-haven.org> wrote:

That's weird... I haven't gotten more than a glimpse yet but for me it
seems considerably faster (typing doesn't lack behind anymore). But that
has to be investigated further in the next couple of days ;)


I have not had any issues with typing lagging behind. Neither on older
releases or the current release.


>>Now, to see if my guess is correct, how do we customize the startup
>>command line to turn off assertion checking? It would be really
>>interesting to see how much of an effect it is having. If there is no
>>perceived change in performance, then IDEA has a lot of profiling to do
>>before GM.


AFAIK assertions are turned off by default for Java applications unless
the programmer explicitely enables them. They are not enabled from the
command line but they are probably enabled from within IDEA via
setDefaultAssertionStatus(boolean). Therefore playing with the command
line options might have no impact.


I'm not talking about for my own applications. I am talking about IDEA
itself. I can tell you know that assertions are turned on for the IDEA
application itself. THe exceptions being sent in from the actions I do
are AssertionFailedExceptions. I am well aware of how to turn assertions
on and off for my own applications developed with IDEA.

0

For me it seems at least as fast as 944, and I really think it is faster overall.

0

billwhitelogin wrote:

For me it seems at least as fast as 944, and I really think it is faster overall.


Then I wonder what the deal is on my machine?

startup time is measurably slower, and error highlighting is also measurably
slower.

0

I think it is really obvious that Build 957 feels much slower than even
the last build.


You know, my build 957 feels faster - it crashes faster :(

Tom

0

Berin Loritsch <bloritsch@d-haven.org> wrote:

I'm not talking about for my own applications. I am talking about IDEA
itself. I can tell you know that assertions are turned on for the IDEA
application itself. THe exceptions being sent in from the actions I do
are AssertionFailedExceptions. I am well aware of how to turn assertions
on and off for my own applications developed with IDEA.


Sorry, I just read what I wrote... What I really wanted to say: You
might not be able to turn assertions off as they are probably turned on
by Jetbrains from within the code.

Sorry for the confusion,

Dirk Dittert

0

Overall I felt that things were faster --- but it feels like there is longer
delay before the editor reparses/checks for errors/resolves references.
Just my perception.
"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:bn61kb$dca$1@is.intellij.net...

I think it is really obvious that Build 957 feels much slower than even
the last build. For instance, it takes over two and a half minutes just
to bring up IDEA--once everything is parsed and such.

>

When I make a change to a file, it takes about 10 seconds or more to

highlight

all the errors introduced. For example, if I remove a class field I want

to

find all the places it was used. Before, it seemed almost instantaneous.

At

least I saw the results in roughly 2 seconds or less.

>

My guess is that JetBrains introduced a butt-load of assertions into the

code,

because the issues I had on startup were assertion failures. The weight

of all

the error checking seems to be really noticeable.

>

Now, to see if my guess is correct, how do we customize the startup

command line

to turn off assertion checking? It would be really interesting to see how

much

of an effect it is having. If there is no perceived change in

performance, then

IDEA has a lot of profiling to do before GM.

>


0

Charles Eubanks wrote:

Overall I felt that things were faster --- but it feels like there is longer
delay before the editor reparses/checks for errors/resolves references.
Just my perception.


That is my observation as well. In fact, that is why I posted this message.
I would go farther and say that it does not just feel like a longer delay,
but there is a longer delay. Much longer.

It can take anywhere up to 20 seconds to reparse, check for errors, and resolve
references.

Before it was maybe 5 seconds tops.

That and the documented strangeness with the startup time.

0

I second that, re/parsing seems to have slowed down in 957

0

And I forgot to add -- this is feels pretty good to me -- better than
having it trying to reparse and be laggy while I am typing
Perhaps if the reparse lag time was a tune-able for those of us who want
more real-time-like parsing?
Or is it already?

"Charles Eubanks" <ceubanks@alphablox.com> wrote in message
news:bn6ams$1dq$1@is.intellij.net...

Overall I felt that things were faster --- but it feels like there is

longer

delay before the editor reparses/checks for errors/resolves references.
Just my perception.
"Berin Loritsch" <bloritsch@d-haven.org> wrote in message
news:bn61kb$dca$1@is.intellij.net...

I think it is really obvious that Build 957 feels much slower than even
the last build. For instance, it takes over two and a half minutes just
to bring up IDEA--once everything is parsed and such.

>

When I make a change to a file, it takes about 10 seconds or more to

highlight

all the errors introduced. For example, if I remove a class field I

want

to

find all the places it was used. Before, it seemed almost

instantaneous.

At

least I saw the results in roughly 2 seconds or less.

>

My guess is that JetBrains introduced a butt-load of assertions into the

code,

because the issues I had on startup were assertion failures. The weight

of all

the error checking seems to be really noticeable.

>

Now, to see if my guess is correct, how do we customize the startup

command line

to turn off assertion checking? It would be really interesting to see

how

much

of an effect it is having. If there is no perceived change in

performance, then

IDEA has a lot of profiling to do before GM.

>

>
>


0

I have noticed this as well. Incrementally with the 9xx releases, the parsing has gotten slower. 957 seems to have taken a big jump with this. The other problem I have found is synchronization can take forever. If you happen to hit a reparse, sync and GC at the same time, which can easily happen with the default 128M heap size, IDEA can start meditating and take up to 5 minutes to stop.

Unfortunately, my project makes heavy use of XDoclet and all interfaces for EJBs and other objects are generated. If I do a clean build, IDEA gets very upset. It seems to reparse everything instead of creating a checksum for each file and only reparsing if the checksum changes. I try to avoid clean builds whenever possible :)

0

Guys, lets speak in numbers :). Insert these lines in your log.xml
inside log4j:configuration tag (it is in $IDEA_HOME/bin):

]]>
I think it will work. If no please send me a message (there could be
some problems with scrambled code). You'll see something like:

-


DEBUG - n.impl.GeneralHighlightingPass - Java highlight: 457
element: 'fullPath' class
com.intellij.psi.impl.source.tree.java.PsiReferenceExpressionImpl; size:8
DEBUG - n.impl.GeneralHighlightingPass - Java highlight: 92
element: 'ArrayList<' class
com.intellij.psi.impl.source.PsiJavaCodeReferenceElementImpl; size:23
...
DEBUG - n.impl.GeneralHighlightingPass - totalTime = 0.24s
for 1005 elements
-


last totalTime is what you are talking about (the highlighting/resolve
part). Try this on 944 and 957. I don't think you'll have noticeable
differences but if you do please send me a message or post a bug with
your example.

Thanks,
IK

Berin Loritsch wrote:

Charles Eubanks wrote:

>> Overall I felt that things were faster --- but it feels like there is
>> longer
>> delay before the editor reparses/checks for errors/resolves references.
>> Just my perception.


That is my observation as well. In fact, that is why I posted this
message.
I would go farther and say that it does not just feel like a longer
delay,
but there is a longer delay. Much longer.

It can take anywhere up to 20 seconds to reparse, check for errors, and
resolve
references.

Before it was maybe 5 seconds tops.

That and the documented strangeness with the startup time.



--
Igor Kuralenok
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"


0

Igor Kuralenok (JetBrains) wrote:

last totalTime is what you are talking about (the highlighting/resolve
part). Try this on 944 and 957. I don't think you'll have noticeable
differences but if you do please send me a message or post a bug with
your example.


I tested this with a few classes of varying sizes.

140 lines: totalTime = 0.203s for 1689 elements
343 lines: totalTime = 0.703s for 3216 elements
349 lines: totalTime = 0.5s for 3698 elements
1012 lines: totalTime = 2.484s for 11236 elements
1014 lines: totalTime = 2.047s for 12231 elements
1329 lines: totalTime = 6.125s for 18432 elements
1467 lines: totalTime = 6.016s for 23119 elements
2327 lines: totalTime = 7.954s for 25483 elements
4847 lines: totalTime = 22.563s for 71851 elements

The last huge class is a special case -- it's a recursive descent parser
which is a bit difficult to split into multiple classes.

This is on a 1.8 GHz P4 with 1 GB of RDRAM.

0

Jonas Kvarnström wrote:

Igor Kuralenok (JetBrains) wrote:

>> last totalTime is what you are talking about (the highlighting/resolve
>> part). Try this on 944 and 957. I don't think you'll have noticeable
>> differences but if you do please send me a message or post a bug with
>> your example.


I tested this with a few classes of varying sizes.

140 lines: totalTime = 0.203s for 1689 elements
343 lines: totalTime = 0.703s for 3216 elements
349 lines: totalTime = 0.5s for 3698 elements
1012 lines: totalTime = 2.484s for 11236 elements
1014 lines: totalTime = 2.047s for 12231 elements
1329 lines: totalTime = 6.125s for 18432 elements
1467 lines: totalTime = 6.016s for 23119 elements
2327 lines: totalTime = 7.954s for 25483 elements
4847 lines: totalTime = 22.563s for 71851 elements

The last huge class is a special case -- it's a recursive descent parser
which is a bit difficult to split into multiple classes.

This is on a 1.8 GHz P4 with 1 GB of RDRAM.


If I get you right it's for the first time highlighting. For second time
results should be a bit better (change something in the class body to
force the full reparse). What's about previous build?

Thanks,

IK



--
Igor Kuralenok
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Igor Kuralenok (JetBrains) wrote:

If I get you right it's for the first time highlighting.


Yes, it is. I should have written that explicitly.

For second time
results should be a bit better (change something in the class body to
force the full reparse). What's about previous build?


Yes, that's quite a lot faster, though it's different from time to time.
I'll have to check that when I have some more time, right now I
unfortunately have some other work to do.

0

These are my experiences exactly. 957 is much slower for me too.

0

Hi Jonas!

Thank you very much for your analysis.

Jonas Kvarnström wrote:

Yes, it is. I should have written that explicitly.

Usually we deal with second time highlighting, that's why this number is
important.

Yes, that's quite a lot faster, though it's different from time to time.

We made some more caching in 957 and expected better results on big
files (which our performance tests show). But, yes it could reduce
performance on small classes that are build on the top of large
hierarchies (JComponent, etc.).

Thanks,
IK

--
Igor Kuralenok
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Igor Kuralenok (JetBrains) wrote:

For second time
results should be a bit better (change something in

the class body to

force the full reparse). What's about previous

build?

Yes, that's quite a lot faster, though it's different
from time to time.
I'll have to check that when I have some more time,
, right now I
unfortunately have some other work to do.


I have seen scenarios with 957 where secondary reparses take quite a bit of time, but are not consuming large amounts of CPU (actually, doesn't seem to be consuming any CPU).

I'm undecided as to whether I should file a bug report, unless I can quantify and refine the problem.

Mike

0

Igor Kuralenok (JetBrains) wrote:

Hi Jonas!

Thank you very much for your analysis.

Jonas Kvarnström wrote:

>> Yes, it is. I should have written that explicitly.


Usually we deal with second time highlighting, that's why this number is
important.

>> Yes, that's quite a lot faster, though it's different from time to time.


We made some more caching in 957 and expected better results on big
files (which our performance tests show). But, yes it could reduce
performance on small classes that are build on the top of large
hierarchies (JComponent, etc.).


Hmmm....

According to the log, the GeneralHighlightingPass itself does not take long
at all. In fact the longest it ever took was 1.722 seconds which is more than
reasonable.

The thing is that during the same session, the set of highlighting on the screen
did not change for much longer than that. I would have included a stack trace--
if there was one to include.

One thing that I did to make the apparent problem happen this time is that I
opened up a project with a couple files that referenced interfaces that were
outside the defined project source directories (someone moved where they were).
When I added the new path back in the project, there was a short time of parsing
(a second or two), and then the errors remained highlighted on the open files.
I had to switch to another application and back to IDEA to force a redraw of the
screen. Once that happened, the source file looked green again.

I have no stack trace for you, so the problem is not the processing speed, it
is the lack of screen refresh.

0

Dirk Dittert <dittert@despammed.com> wrote:

That's weird... I haven't gotten more than a glimpse yet but for me it
seems considerably faster (typing doesn't lack behind anymore). But that
has to be investigated further in the next couple of days ;)


Ok, I worked on my old project for a while (the one that I couldn't work
on with the last EAP builds). Editing speed is now comparable with 3.0.x
again. Typing doesn't lag behind anymore.

Thank you!

Dirk Dittert

0

I noticed that there are issue with UI forms parsing in 957 too.
The form code - I use the UI codegen switch in project properties - gets generated every time on 'compile' or 'run' and the form or source is not touched at all. Even when doing a build first and then run the app Idea goes to parse the form again and make the project.
Also, it generates the different code often for the same form. Ordering of the Swing components properties gets changed, and this makes the CVS thinks it needs to check in the form every time. This all was ok in 944.

0

Please sign in to leave a comment.