Continuous compilation

Hi.

Can someone tell me why we need continuous compilation?

Thanks,
Amnon

0
34 comments

I was always curious how is it going to work in a project with a lot of generated code.. xdoclet, javacc and so on.

0

Jonas Kvarnström wrote:

Dave Griffith wrote:

>> Maxim may have better information, but the short answer is, you're
>> wrong. For all but a handful of inspections, processing time is not
>> the issue. The bulk of time spent by inspections is either the pure
>> I/O involved in parsing the files into internal PSI trees, or
>> resolving external references, which also seems to be mostly I/O
>> against disk caches and indices. The tricky bits of inspection,
>> walking trees and checking for possible error conditions, are
>> otherwise essentially free. The cost of an inspection or error
>> annotation is almost entirely related to how much external reference
>> resolution it has to do, and whether those resolutions hit the
>> internal caches or not.


In this case I think you have another definition of "I/O-intensive" and
"CPU-intensive" than I have. When I'm waiting for all the inspections
to finish analyzing the file I'm working with, the CPU meter is
generally pegged at 100% and the hard disk LED is completely dark,
because everything is already in RAM. To me this would mean that the
process is CPU-intensive, even though it may be external method calls
for reference resolution that uses all that CPU time, rather than the
inspection code itself. Or have I misunderstood something in your
argument? It's late and I'm a bit tired...

I had a reply quite like this one in the making, but I've been busy, and
as yours is quite eloquent enough, I won't bother repeating you :)
Suffice to say +1.

To continue the discussion, I see very little chance that idea will
cause contention with other applications while it works in the
background, if we are indeed correct about what it will do with the few
cycles it gets thrown.

I still regularly curse IDEA for not continuing with inspections when it
loses focus, though. It's quite annoying having to wait a full minute
in some cases without being able to do anything else like having
Thunderbird in the foreground, reading a few newsgroup posts (which
consumes maybe all of 0.1% of the CPU on average, given the idle time
when I'm just reading something, leaving 99.9% for IDEA to waste).

Glad someone else shares the same working manner as me, and the same
frustrations!

N.

0

Jonas Kvarnström kirjoitti:

Dave Griffith wrote:

>> Maxim may have better information, but the short answer is, you're
>> wrong. For all but a handful of inspections, processing time is not
>> the issue. The bulk of time spent by inspections is either the pure
>> I/O involved in parsing the files into internal PSI trees, or
>> resolving external references, which also seems to be mostly I/O
>> against disk caches and indices. The tricky bits of inspection,
>> walking trees and checking for possible error conditions, are
>> otherwise essentially free. The cost of an inspection or error
>> annotation is almost entirely related to how much external reference
>> resolution it has to do, and whether those resolutions hit the
>> internal caches or not.


In this case I think you have another definition of "I/O-intensive" and
"CPU-intensive" than I have. When I'm waiting for all the inspections
to finish analyzing the file I'm working with, the CPU meter is
generally pegged at 100% and the hard disk LED is completely dark,
because everything is already in RAM. To me this would mean that the
process is CPU-intensive, even though it may be external method calls
for reference resolution that uses all that CPU time, rather than the
inspection code itself. Or have I misunderstood something in your
argument? It's late and I'm a bit tired...

I still regularly curse IDEA for not continuing with inspections when it
loses focus, though. It's quite annoying having to wait a full minute
in some cases without being able to do anything else like having
Thunderbird in the foreground, reading a few newsgroup posts (which
consumes maybe all of 0.1% of the CPU on average, given the idle time
when I'm just reading something, leaving 99.9% for IDEA to waste).


I think, that when everything is in cache, situation looks like CPU
intensive, but when memory goes low (after task switching), it becomes
to be true I/O problem with swapping (with memory mapped files?).

Similar problem have been seen with Diskeeper defragmenter, while trying
to set its priority to lowest possible value on background, indused
pagefaults occassionaly slows system dramaticaly when large file is been
defragmented.

In windows you can use Performance Monitor to see CPU, memory, and
disk+net I/O graphs. I have those graphs allways visible on second
screen, so that I allways know, what resource is causing sudden problem
at each time.

On other hand, inspections are stateless and independent, and when lot
of them are enabled, lot of similar computations are repeated parallel
without reusing intermediate results of individual inspections. That
increases need of cycles.

- Olli -

0

On other hand, inspections are stateless and independent, > and when lot of them are enabled, lot of similar
computations are repeated parallel without reusing
intermediate results of individual inspections. That
increases need of cycles.

- Olli -


Hi Olli, nice to see that I'm not the only Finn lurking in these forums. =)

I've had some situations with our codebase where I'd love to have done 'inspection like' computations so that they use at least some of the results from the other 'inspections'.

However, going for the simple independent (parallel or not) route produces much simpler and maintainable code in a fraction of the time. In a perfect world with unlimited number of resources - optimization is always the best solution.

The current performance regarding to inspections is adequate - IMO. At least that holds true on my current gear (Mobile P4 1.6Ghz/1GB). I have most of them enabled and Idea seems to churn out happily informing me about things like unused resource strings and too long local variable names.. =) - Yeah, I'm spoiled by the CTRL+Space..

Continuos inspections where a step to the 'traditional intellij IDEA' direction. Continuos compilation is a step towards Eclipse and you cannot win that fight since the competitor is free. Develop your own strengths and ideas and you'll maintain the edge.

P.S.
I'm still waiting for the Subversion stuff to be reliable enough to warrant the change from CVS. Please fix that first before even thinking about continuos compilation..



0

Please sign in to leave a comment.