IntelliJ 4.0 very slow to repase JARs

I have done the following test:
1. Open IntelliJ
2. Open a project
3. Recopy all library jar files
4. Click the IntelliJ window

Result: the JARs were reparsed (recached).

There is a huge speed difference between 3.0.5 and 4.0 (1167).

On 3.0.5 it took 12 seconds.
On 4.0 it took 90 seconds.
On 1180 it took 70 seconds but the project initialization was 7 minutes, a
lot longer than 1167.

Has anyone else done tests such as this?

JetBrains: Are you aware of this, and if not, I'd be happy to run any tests
you want to solve this issue.

Amnon


4 comments
Comment actions Permalink

Yes, everyone has done that, including the JetBrains folks. IDEA 4.0 collects lots more information from jar files that it did on 3.0 -- the result is that it takes more time to parse these files, but then code completion is way faster.

Now, jar parsing is done only once for each jar (unless it changes), and code completion is done all the time. For me, this change was worth it :)

0
Comment actions Permalink

I guess that our environment causes it to be done much more than other
environments, as we have a script that gathers all the necessary jars for
compilation and running, and thus the local jar files get a new modified
time even if they really didn't change, as they are just stomped with the
same file.

Thanks for that info, I'm trying to get JetBrains to add some refinement to
how they detect that a jar file changed as a setting (e.g. by a checksum,
for example) to avoid the redundant parsing in a case that the same file is
just copied on the old file.

Amnon

"Marcus Brito" <pazu@animegaiden.com.br> wrote in message
news:5769717.1081547361074.JavaMail.itn@is.intellij.net...

Yes, everyone has done that, including the JetBrains folks. IDEA 4.0

collects lots more information from jar files that it did on 3.0 -- the
result is that it takes more time to parse these files, but then code
completion is way faster.
>

Now, jar parsing is done only once for each jar (unless it changes), and

code completion is done all the time. For me, this change was worth it :)


0
Comment actions Permalink

If you distribute your JARs using and set it to preserve file dates on copy
so it will not stamp them with date of copy every time. It shoudl solve your
problem

"Amnon I. Govrin" <agovrin@freshwater.com> wrote in message
news:c57a8b$v09$1@is.intellij.net...

I guess that our environment causes it to be done much more than other
environments, as we have a script that gathers all the necessary jars for
compilation and running, and thus the local jar files get a new modified
time even if they really didn't change, as they are just stomped with the
same file.

>

Thanks for that info, I'm trying to get JetBrains to add some refinement

to

how they detect that a jar file changed as a setting (e.g. by a checksum,
for example) to avoid the redundant parsing in a case that the same file

is

just copied on the old file.

>

Amnon

>

"Marcus Brito" <pazu@animegaiden.com.br> wrote in message
news:5769717.1081547361074.JavaMail.itn@is.intellij.net...

Yes, everyone has done that, including the JetBrains folks. IDEA 4.0

collects lots more information from jar files that it did on 3.0 -- the
result is that it takes more time to parse these files, but then code
completion is way faster.
>

Now, jar parsing is done only once for each jar (unless it changes), and

code completion is done all the time. For me, this change was worth it :)

>
>


0
Comment actions Permalink

Problem is, calculating the checksum would take some time too. Not a long time for really small jars, but definetely noticeable for larger ones. I think a better solution is for you is modify your script so you don't copy over jars that hadn't changed (or at least adjust it to keep the original modification time).

0

Please sign in to leave a comment.