RMI Compiler is stupid and slow

I've been testing the RMI compilation in the last 4.1 EAP releases and I'm
quite disappointed with the performance and intelligence in the compiler.
When I first saw that this feature finally would be implemented I was hoping
for a fast and intelligent RMI compiler. When I mean intelligent I hoped
that it should only RMI compile if the RMI interface actually changed and
with fast I hoped this would be faster and smoother than the traditional ANT
scripts.



I've read somewhere in a discussion that the scanner had to deal with
external compilation from ant and this caused the delay, but in my project
with a couple of thousand java files and approximately 40 RMI files it takes
3 to 5 seconds to scan the output directory before I run/debug if I compile
before I start. This it to slow and I often just turn off the RMI compiler
and run the old ANT scripts when I know I've changed some RMI interfaces



I hope that some of these problems will be addressed before the final 4.1
release, at least an option to turn off the scanner for external changes to
speed things up a little



-=Børge Austvold




14 comments
Comment actions Permalink

>. When I mean intelligent I hoped
>that it should only RMI compile if the RMI interface actually changed

Could you give an example when this is not the case?


--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Børge Nygaard Austvold" <borge-nygaard.austvold@4tel.no> wrote in message news:cans51$vja$1@is.intellij.net...

I've been testing the RMI compilation in the last 4.1 EAP releases and I'm
quite disappointed with the performance and intelligence in the compiler.
When I first saw that this feature finally would be implemented I was hoping
for a fast and intelligent RMI compiler. When I mean intelligent I hoped
that it should only RMI compile if the RMI interface actually changed and
with fast I hoped this would be faster and smoother than the traditional ANT
scripts.

>
>
>

I've read somewhere in a discussion that the scanner had to deal with
external compilation from ant and this caused the delay, but in my project
with a couple of thousand java files and approximately 40 RMI files it takes
3 to 5 seconds to scan the output directory before I run/debug if I compile
before I start. This it to slow and I often just turn off the RMI compiler
and run the old ANT scripts when I know I've changed some RMI interfaces

>
>
>

I hope that some of these problems will be addressed before the final 4.1
release, at least an option to turn off the scanner for external changes to
speed things up a little

>
>
>

-=Børge Austvold

>
>
>
>


0
Comment actions Permalink

Eugene Zhuravlev (JetBrains) wrote:
>> . When I mean intelligent I hoped
>> that it should only RMI compile if the RMI interface actually changed
>

Could you give an example when this is not the case?

>

For every change in my RMI-Classes (Build 2118,Windows XP) i get an
'generating RMI Stubs'.
I don't think it's looking at the RMI -Interfaces at all.
And i also find it very disturbing to wait for scanning output directories
with every compile.
(3-5 seconds with 5 RMI-Classes, 1000 java-files altogether, not one of the
RMI-Classes changed).

mfg
Carsten


0
Comment actions Permalink

Ok, we'll address scannng problem.
As for regenerating RMI stubs whenever the remote object is touched - is this a big deal if generating itself works fast?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Isn't it true that you only have to generate the stubs if the signatures or methods have changed in the RMI interface and not if the implementing class have changed ?

So it should be possible to only RMI compile if some methods have changed or you added/removed methods. Maybe it would be enough to mark a checksum of the current methods and launch the RMI compiler only if checksum changed (dont' look at the class files, but the source code of the RMI interface)

So if I change the signature of an RMI interface and use ant to generate the stubs idea will still generate new stubs next time it compiles since it doesn't look at the class files. This is OK since I probably only will use IDEA to compile RMI interfaces since it's so smart that it doesn't recompile if only the implementation of the methods changed.

Maybe ? :)

PS! Sorry for my bad english :)


0
Comment actions Permalink

Eugene Zhuravlev (JetBrains) wrote:

Ok, we'll address scannng problem.
As for regenerating RMI stubs whenever the remote object is touched -
is this a big deal if generating itself works fast?

No thats not the big deal.
The Big deal is the 'scanning output directories' that comes every time even
if no RMI-class is touched
(i think even when no class is touched at all).


0
Comment actions Permalink

well, changes to the interface will result in changes to the implementing class: the class will be changed in order to reflect
interface changes either by you or by make. So we may say simplier: "whenever the remote object is changed, we should recompile the
stubs". Sure it will also recompile stubs even if the object is simply touched, but this is not a big deal (see my previous post):
comparing to the time needed to find remote files, stub generation is performed fast.


--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Borge Nygaard Austvold" <no_mail@jetbrains.com> wrote in message news:12609096.1087410066492.JavaMail.itn@is.intellij.net...

Isn't it true that you only have to generate the stubs if the signatures or methods have changed in the RMI interface and not if

the implementing class have changed ?
>

So it should be possible to only RMI compile if some methods have changed or you added/removed methods. Maybe it would be enough

to mark a checksum of the current methods and launch the RMI compiler only if checksum changed (dont' look at the class files, but
the source code of the RMI interface)
>

So if I change the signature of an RMI interface and use ant to generate the stubs idea will still generate new stubs next time it

compiles since it doesn't look at the class files. This is OK since I probably only will use IDEA to compile RMI interfaces since
it's so smart that it doesn't recompile if only the implementation of the methods changed.
>

Maybe ? :)

>

PS! Sorry for my bad english :)

>
>
>


0
Comment actions Permalink

I really don't see why you have to recompile the stub if only the remote object change. About 90% of the time we ONLY change the implementing methods and not the RMI interface and for those 90% of the cases we only need to run javac on the file and not RMIC

0
Comment actions Permalink

Sure. But checks whether the interface has changed will take longer than realizing that the file's timestamp changed and recompiling
the stubs.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Borge Nygaard Austvold" <no_mail@jetbrains.com> wrote in message news:29189981.1087478967780.JavaMail.itn@is.intellij.net...

I really don't see why you have to recompile the stub if only the remote object change. About 90% of the time we ONLY change the

implementing methods and not the RMI interface and for those 90% of the cases we only need to run javac on the file and not RMIC


0
Comment actions Permalink

I see your point, but we are talking about two things here.

The first part it to figure out what we have to RMI compile and the second part is the actual compilation. I guess if you speed up the detection phase, but don't add more logic to what to compile you only have solved half the problem since you end up compiling a lot of classes that could have been skipped.

Anyway I would be very happy If the delay of "scanning output dirs" could be reduced...

0
Comment actions Permalink

I guess to demonstrate the problem you could try to add a few RMI classes just for testing in the source code of IDEA project (probably contains a LOT of classes and modules :)

Turn on the RMI compiler and test around to see the delays. Then try to change the implementation of an RMI interface and see what happens :)

0
Comment actions Permalink

Please check for improvements the build that will appear after #2126.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"Borge Nygaard Austvold" <no_mail@jetbrains.com> wrote in message news:25193040.1087492482056.JavaMail.itn@is.intellij.net...

I guess to demonstrate the problem you could try to add a few RMI classes just for testing in the source code of IDEA project

(probably contains a LOT of classes and modules :)
>

Turn on the RMI compiler and test around to see the delays. Then try to change the implementation of an RMI interface and see what

happens :)


0
Comment actions Permalink

I sure will... tanks a lot :)

0
Comment actions Permalink

Wow!

The "scanning output directories" delay is gone an the RMI compilation now works a lot smoother. Thanks a lot!!!

Now I can turn on RMI compilation and continue working without running ANT scripts.

Just one more problem. I added a new line character in a RMI implementation class and the RMI compiler recompiled the class. However I can live with this since this is the normal behavior of other IDE's and the way ANT works. Maybe this will be fixed/optimized for 4.6/5.0 ? :)

Thanks again!

0
Comment actions Permalink

You are welcome.
Please don't hesitate to post any coments/suggestions.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"Borge Nygaard Austvold" <no_mail@jetbrains.com> wrote in message news:33255127.1087605720446.JavaMail.itn@is.intellij.net...

Wow!

>

The "scanning output directories" delay is gone an the RMI compilation now works a lot smoother. Thanks a lot!!!

>

Now I can turn on RMI compilation and continue working without running ANT scripts.

>

Just one more problem. I added a new line character in a RMI implementation class and the RMI compiler recompiled the class.

However I can live with this since this is the normal behavior of other IDE's and the way ANT works. Maybe this will be
fixed/optimized for 4.6/5.0 ? :)
>

Thanks again!



0

Please sign in to leave a comment.