| Large jar on InPath [message #50943] |
Sat, 23 April 2005 07:35  |
Eclipse User |
|
|
|
I have a somewhat large jar on the InPath of my aspectj project (about 4M). I only need to weave a very few classes out of this jar, but do not own the jar and cannot have it built as smaller jars. Any incremental compile seems to require scanning the entire jar each time. The progress quickly goes to 11%, then spends about 30 seconds there before completing. This means 30 seconds for every single incremental compile. Not very productive.
Is there any way to speed this up? Are InPath jars cached in any way? Can they be?
When I try to edit the 'Access rules' for the InPath jar no dialog is presented (ie, I click the button but nothing happens). It seems that filtering the classes considered for weaving via the access rules would be my problem solver. Is this is a known problem, or just not implemented? Need I file a bug?
(eclipse 3.1M6, java5 compiler, ajdt build 1.2.0 20050420095141)
thanks!!
-barry
(BTW, this is in a freshly created project. I still cannot get around the compile error I posted the other day for a different exiting project.)
|
|
|
|
|
| Re: Large jar on InPath [message #51083 is a reply to message #51055] |
Mon, 25 April 2005 08:30  |
| Eclipse User |
|
|
|
Originally posted by: clemas.uk.ibm.com
Hi Barry,
There is a lot for us to do in the area of improving incremental
compilation, we have these bugs open right now:
85297 Improvements to incremental compilation
83890 incremental: only do a full build if pointcuts change
83891 incremental compiles should handle file deletion gracefully
83894 incremental: output weave times & files woven & heuristics
The most active one is the top one where I am appending notes on my
changes as I make them. I'm really tackling the problems in the order
that affects most people - right now that is people with multiple
inter-dependant AJ projects (for example the AJDT project itself!), the
compile times are a killer and I'm hoping to provide some fixes in that
area this week.
Your comment about fast builds unless you modify an aspect is covered by
83890.
On the large jar thing - it doesn't matter that you are using withincode
to try and limit what is matched, the compiler still needs to open all
the classes up to see which members are matched by your withincode
pointcut. within() which works at the type level would be a better
choice than withincode() actually - but how much that might affect your
compile times, I'm not sure. Chatting with the AJDT team, the access
rules you have been specifying are ignored by AJDT - but we could think
about supporting them to cope with large jars - if you have
findings/complaints/timings, please append them to 85297.
cheers,
Andy.
|
|
|
| Re: Large jar on InPath [message #587856 is a reply to message #50943] |
Sat, 23 April 2005 08:14 |
| Eclipse User |
|
|
|
I just noticed that /all/ classes form the InPath jar are included in the my projects output classes. My very simple aspect is a call && withincode (ie, a single static method call in a single class). What is the compiler doing with all these classes?
-barry
|
|
|
| Re: Large jar on InPath [message #587874 is a reply to message #50943] |
Sat, 23 April 2005 12:40 |
| Eclipse User |
|
|
|
I should add that the slow compile only occurs when an aspect is modified. When only regular java files are modified the compile is normal (ie, fast).
-barry
|
|
|
| Re: Large jar on InPath [message #587884 is a reply to message #51055] |
Mon, 25 April 2005 08:30 |
| Eclipse User |
|
|
|
Hi Barry,
There is a lot for us to do in the area of improving incremental
compilation, we have these bugs open right now:
85297 Improvements to incremental compilation
83890 incremental: only do a full build if pointcuts change
83891 incremental compiles should handle file deletion gracefully
83894 incremental: output weave times & files woven & heuristics
The most active one is the top one where I am appending notes on my
changes as I make them. I'm really tackling the problems in the order
that affects most people - right now that is people with multiple
inter-dependant AJ projects (for example the AJDT project itself!), the
compile times are a killer and I'm hoping to provide some fixes in that
area this week.
Your comment about fast builds unless you modify an aspect is covered by
83890.
On the large jar thing - it doesn't matter that you are using withincode
to try and limit what is matched, the compiler still needs to open all
the classes up to see which members are matched by your withincode
pointcut. within() which works at the type level would be a better
choice than withincode() actually - but how much that might affect your
compile times, I'm not sure. Chatting with the AJDT team, the access
rules you have been specifying are ignored by AJDT - but we could think
about supporting them to cope with large jars - if you have
findings/complaints/timings, please append them to 85297.
cheers,
Andy.
|
|
|
Powered by
FUDForum. Page generated in 0.02984 seconds
Home