IDEA Background Tasks 7241

IDEA's 7.0 improvements on running more tasks in the background and making
better use of multi-cpu machines is one of the top 10 features, and personally
my #1 feature of this release, mainly because the syntax and inspections parse
feels 2X faster on my dual core workstation.

When IDEA 7.0 is released, Jetbrains marketing should really highlight this feature.
This is a very visible improvement that everyone should appreciate, unlike many of
the new features which have more limited audience or improve features used less often.
I see in the roadmap it says:
(http://www.jetbrains.net/confluence/display/IDEADEV/Selena+Roadmap)

"More operations performed in background (Find Usages, VCS update etc.)"

Eliminating all those modal progress dialogs is super nice, but that isn't
the most exciting change. IDEA feels much faster to me because when I load a
file, the syntax and inspection parse appears to be up to 2X faster! And Inspect
Code is also faster.
I would have a some graphs showing show time taken to (1) highlight a large file
and (2) Inspect Code on a project with (1) IDEA 6.0 (2) IDEA 7.0 with single
core (3) IDEA 7.0 with dual core, and (4) IDEA 7.0 with quad core.

I think I saw a Jetbrains developer mention in a Jira that IDEA will scale up
now according to how many cpus you have (Using Runtime.availableProcessors()? )
It would be nice if Jetbrains could clarify exactly which features make use of
multiple cores now. And some empirical tests showing big improvements on dual
core and quad core workstations could really get IDEA users excited to upgrade!

Personally, If I knew for sure that the syntax+inspections parse will speed up
another 2X from dual core to quad core, I'll be looking to get a quad core
workstation right away.

Recently, Intel just dropped the price on it's cheapest Quad Core chip to $266
(Ref. http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3066)

I said last year, that dual core was becoming mainstream, and it pretty much is
now, even for laptops people are getting dual core machines. Now I see for
professional workstations, there is movement to quad core workstations where it
can be justified. That trend should accelerate now that the price has the chips has
dropped 50% the past few months.

Below I will post additional feedback since my last post.

Other Thread: IDEA Background Tasks (As of IDEA 6.0.3 build 6141)
http://www.intellij.net/forums/thread.jspa?threadID=265415

20 comments
Comment actions Permalink

As I said, I really like the almost 2X speedup in the syntax and inspections parse when I load a file into the Editor. When I load a file, I can see both of my dual cpu% spike to 100%.

However, I noticed that if I jump to a file and then start navigating around the file, then the syntax/inspections parse gets stalled. I know this was done to make IDEA responsive when the user is interacting with it.

There is an autoreparse delay setting which I have set to 100 ms (I think the default is 300ms). So 100ms after I stop hitting a key in the Editor pane, I see both cpus kick back to 100% until the syntax/inspections parse is complete.

You can see the current behavior better if you change your auto-reparse delay setting to a larger number like 500 ms. Load a large file, and immediately start navigating around. On my machine, I see cpu only around 10%. Then if I stop navigating around, then the cpu shoots up to 100% as the parsing threads start again.

I think if you are running multi-core, then only 1 of your processors should be subject to stalling on user input, and forced to wait for the autoreparse delay before resuming.

The other n-1 threads should continue to parse the current editor file, unless the user loads a different file.

So if you have dual-core, then 1 process thread should continue the parse, and only the remaining processor should be subject to the autoreparse delay. If I have quad-core, then 3 process threads should continue to parse uninterrupted by user keypresses, and the remaining process thread will kick in if I stop pressing keys for more than autoreparse delay.

Doing the above we give us the maximum performance boost for dual core and quad core workstations running IDEA.

0
Comment actions Permalink

IDEA 7.0 has added more settings to whether tasks are in the background. As I
talked about in my previous post, "Search in background" really means is just
"Show search progress in the status bar instead of in a modal progress dialog",
"Compile in background" means only "Don't lock up the console while compiling."
From this perspective, IDEA currently does not truly run any search, compile,
ant tasks, etc. in the background -- they are still running in the foreground
because they are popping up output tool windows and populating them and then
upon completion they steal the focus from the editor. Only the task progress
updates have been moved into the background. The only task I would classify
as truly a background task is the file synchronization.

I think Jetbrains should take this opportunity to clean up the terminology.
Personally, I think most of these settings can be removed since nobody should ever
want to show progress in the foreground in a modal progress dialog!

For tasks where the output is unimportant unless there is an error -- I called
these INTERACTIVE_ON_ERROR tasks -- IDEA needs to support a true Background option
so, for example, I can avoid popping up a Run Output tool panel when I am launching
my appliction from IDEA or avoid popping up a Messages tool panel when I use IDEA's
Compile or execute an Ant task where I dont' care about seeing the output unless there
is an error.

Here is summary of changes I suggest:

1) Remove all current settings like "Compile in background", "Search in
background", "Make build in background" (Ant), etc.

Or failing that, they should be renamed to "Compile progress in background",
"Search progress in background", "Build progress in background", etc.

And the default should be ON!

2) For Compile, there should be a new option 'Compile in background, show on error'
Note: The compile output should still be populated, but it should only
be poppped up on error. Furthermore, upone task completion, it should NOT
steal the focus.

3) For Run Configurations, there should be an option 'Run in background'

Note: The Run Output should still be populated, but it shouldn't be popped
up by default. That way if someone is running UI programs where they don't
care about the output, they can avoid popping up the Run Output tool panel.

4) For Ant build.xml configuration, add a new option 'Make build in background,
show on error'

Note: The Ant Messages window should still be populated, but should only be
displayed on error. Furthermore, upon task completion, the the focus should
NOT be stolen from the Editor window.

I have many ant tasks which I never care to see the output unless there is
some kind of error which is extremely rare. Tasks like 'compile', 'package',
'deploy', 'deploy-remote', etc.

0
Comment actions Permalink

Here are some related Jiras.

Ant integration: make an option to run ant projects in background by default
http://www.jetbrains.net/jira/browse/IDEADEV-12660

During compilation Compile tool window pops up (if you choose to compile in background) even if there are no errors.
http://www.jetbrains.net/jira/browse/IDEA-13682

0
Comment actions Permalink

Hello Alex,

IDEA's 7.0 improvements on running more tasks in the background and
making better use of multi-cpu machines is one of the top 10 features,
and personally my #1 feature of this release, mainly because the
syntax and inspections parse feels 2X faster on my dual core
workstation.

When IDEA 7.0 is released, Jetbrains marketing should really highlight
this feature.
This is a very visible improvement that everyone should appreciate,
unlike many of
the new features which have more limited audience or improve features
used less often.
I see in the roadmap it says:
(http://www.jetbrains.net/confluence/display/IDEADEV/Selena+Roadmap)
"More operations performed in background (Find Usages, VCS update
etc.)"

Eliminating all those modal progress dialogs is super nice, but that


IMHO, there are still many left:
-Checkout (SVN,CVS,others?): IDEADEV-17249
-"Getting content revisions" (CVS,before diff): IDEA-13628
-likely many others

isn't
the most exciting change. IDEA feels much faster to me because when I
load a
file, the syntax and inspection parse appears to be up to 2X faster!
And Inspect
Code is also faster.
I would have a some graphs showing show time taken to (1) highlight a
large file
and (2) Inspect Code on a project with (1) IDEA 6.0 (2) IDEA 7.0 with
single
core (3) IDEA 7.0 with dual core, and (4) IDEA 7.0 with quad core.
I think I saw a Jetbrains developer mention in a Jira that IDEA will
scale up now according to how many cpus you have (Using
Runtime.availableProcessors()? ) It would be nice if Jetbrains could
clarify exactly which features make use of multiple cores now. And
some empirical tests showing big improvements on dual core and quad
core workstations could really get IDEA users a reason to upgrade!

Personally, If I knew for sure that the syntax+inspections parse will
speed up another 2X from dual core to quad core, I'll be looking to
get a quad core workstation right away.


I strongly agree with everything in your post.

In addition, is there any potential for a speedup (through concurrency) for
these?
-running JUnit/TestNG tests
-scanning JARs/source
-index building

Taras


0
Comment actions Permalink

In addition, is there any potential for a speedup (through
concurrency) for
these?
-running JUnit/TestNG tests
-scanning JARs/source
-index building


I'm also curious about search - is it already concurrent?
At least on my system some search queries push the (single) CPU to 100%.

-tt


0
Comment actions Permalink

>I strongly agree with everything in your post.

As do I.

+
In addition, is there any potential for a speedup (through concurrency) for
these?
-running JUnit/TestNG tests+

Hmm, I honestly don't know how many of my unit tests are actually thread-safe and non-conflicting. Probably not very many. Certainly any that hit a database are going to be problematic to run in parallel. Possibly an @Isolated annotation would allow the runner to run tests in multiple threads, trusting the programmer's word that the test wouldn't interact with anything else. Something to run by the JUnit/TestNG people, anyway.

That said, I would absolutely love to be able to run JUnit tests (sequentially) in the background, get status-line indication of test completion/failure, and only open the results toolwindow if something goes wrong. Even better if I could specify a set of tests as running continuously in the background (at very low priority).

--Dave Griffith

0
Comment actions Permalink

Dave Griffith wrote:

That said, I would absolutely love to be able to run JUnit tests
(sequentially) in the background, get status-line indication of test
completion/failure, and only open the results toolwindow if something
goes wrong. Even better if I could specify a set of tests as running
continuously in the background (at very low priority).


Don't we have C.I. servers for that functionality? :)

0
Comment actions Permalink

Alex - why don't you create JIRA issue(s) as well?
Thanks,
Jon

0
Comment actions Permalink

While intended as a joke, it's actually a pretty interesting question, and one I'm not really sure of the answer for. Continuous integration servers with tight IDE feedback (which is to say TeamCity) are pretty excellent at providing "state-of-the-checkpoint" visibility. What I'm thinking of with a "continuous testing" is more "state-of-the-edit" visibility. C.I. reduces the feedback loop from hours (or days) to minutes. What I'm talking about would reduce it from minutes to seconds. That sort of thing may be overkill (we are software developers, not fighter pilots or air traffic controllers), but it certainly seems like it's worth experimenting with.

--Dave Griffith

0
Comment actions Permalink

Hello Dave,

servers with tight IDE feedback (which is to say TeamCity) are pretty
excellent at providing "state-of-the-checkpoint" visibility. What I'm
thinking of with a "continuous testing" is more "state-of-the-edit"
visibility. C.I. reduces the feedback loop from hours (or days) to
minutes. What I'm talking about would reduce it from minutes to
seconds. That sort of thing may be overkill (we are software
developers, not fighter pilots or air traffic controllers), but it
certainly seems like it's worth experimenting


My personal experience is that it's pretty distracting.
It breaks the "code-test" cycle by providing feedback too soon: having a
"red bar" while you're just trying to code some feature is not a nice feeling.

Taras


0
Comment actions Permalink

Ok, I finally found some time to file some Jiras on these issues.
But first, I need to mention that one of the items "Compile in background, show on error"
is already implemented in Selena EAP. I hadn't noticed, because I use Ant to build
3 or the 4 projects I work on.

So the following Jira is already Fixed:

During compilation Compile tool window pops up (if you choose to compile in background) even if there are no errors.
http://www.jetbrains.net/jira/browse/IDEA-13682

IDEA uses the same 'Compile in background' for this new setting.

--

Now for remaining items.

I want the Ant compilation to work exactly like the Build->Make Project works when
'Compile in background' is enabled. If you have 'Make build in background'
checked in Ant Tool window properties for your build.xml file, then when
executing a task it should run in the backgrouind, without showing the ant
output toolwindow unless there is an error, and showing progress in the status
bar/background tasks popup window.

Currently, even with 'Make build in background' option checked, Ant immediately
displays and populates the output toolwindow and upon completion steals focus to
that window. Furthermore, the ant task execution progress is NOT shown in the status
bar and background tasks window.

Ant integration: 'Make build in background' should only show output window on error, show task progress in status bar/background tasks window
http://www.jetbrains.net/jira/browse/IDEA-14881

I like how Eclipse has a single 'Run tasks in background' setting which applies
to everything. I don't think someone is going to want to Compile in background
but Search in the foreground!

I think this is one place where I like Eclipse's simple approach better by just having
a single setting 'Run tasks in background' that replaces all these individual settings
s Compile in Background, Make build in background, Search in background,
Perform VCS in background, etc.

IDE Settings: General: Add 'Run tasks in background' to replace Compile in background, Search in background, Ant 'Make Build in Background', Perform VCS in Background, etc.
http://www.jetbrains.net/jira/browse/IDEA-14882

Ant tasks are more general purpose, though, so someone might have some tasks
who output their results on the commandline, so maybe the ideal solution would
be to retain the 'Make build in background' setting on each individidual build.
xml file, but use the IDE General 'Run tasks in background' setting as the
default value for 'Make build in background' whenever you add a new build.xml
file to your Ant Tool window.

Ant integration: make an option to run ant projects in background by default
http://www.jetbrains.net/jira/browse/IDEADEV-12660

On separate topic, I would like 'Run in background' option to be available for
Run configurations. I have several GUI programs I launch from IDEA, and I never
use the output window, so I'd like the option to not have it pop up. But, I would
still like IDEA to populate the output window behind the scenes so I could
click on the Run tab to check the output if I wanted to.

Run Configuration: Should have option to 'Run in background'
http://www.jetbrains.net/jira/browse/IDEA-14883

0
Comment actions Permalink

I filed a Jira for this. If it is technically feasible, I think this would make IDEA appear even faster, esp. when you have QUAD cores.

Optimize Editor Syntax/Inspection parse for multi-cores, limit autoreparse delay to only 1 out of n cores.
http://www.jetbrains.net/jira/browse/IDEA-14683

0
Comment actions Permalink

Even though synchronization is done in the background, there are still some IDE cache updates which are happening in the foreground.

You might notice modal dialogs popping up that say:
Loading Files.. Scanning Files.. Parsing Files.. Building Indices.

There is already a Jira for this issue. Apparantly it is a risky change, so it may or may not make Selena.

Background CacheUpdaters
http://www.jetbrains.net/jira/browse/IDEADEV-12074

0
Comment actions Permalink

Hello Alex,

Did you already create a JIRA ticket for concurrent "Find Usages"?

Taras


0
Comment actions Permalink

I was just thinking about that myself. Find Usages is currently not multithreaded. On a dual-core or quad-core machine running latest EAP, you will only see one cpu busy when you run Find Usages. (Also Find in Path).

Find Usages is probably the #1 candidate now for a multi-core makeover. Try running Find Usages on a big class and check 'Usages of methods". It takes minutes and minutes to complete.

There is an old Jira IDEABKL-260 filed already "Find usages support multiple processors", but the priority is Minor. Well, the priority is more like CRITICAL now because everybody has DUAL and QUAD core workstations that are sitting around spinning their wheels while Find Usages runs.

Selena EAP already has the big improvement in syntax/inspections parse using multi cores. (I haven't quantified exact speedup but both my cpus are maxxed out when I load a large Java file, so maybe it's close to 2X speedup).

Jetbrains needs to keep making long running tasks multi-core ready, because most developers at big companies now have DUAL core workstations, and it won't be long before we're running QUAD core. AMD just came out with their Barcelona Quad core chip (http://www.tgdaily.com/content/view/33762/135/), and later this fall, Intel is coming out will a bunch of 45nm QUAD core parts. The price is dropping rapidly, and I'm expecting QUAD cores to be plentiful in 2008 for engineering / graphics workstations.

I think if Jetbrains can fully harness a QUAD core workstation, then that would help their reputation as the professional's choice for Java IDE editor.


Find usages support multiple processors
http://www.jetbrains.net/jira/browse/IDEABKL-260

Use compiler caches to speed up Find Usages
http://www.jetbrains.net/jira/browse/IDEADEV-12010

Find Usages - Usages of Methods of a Class - Should do one search for each group of overloaded methods in a class
http://www.jetbrains.net/jira/browse/IDEADEV-17409

Problem with finding usages on setName() and getName()
http://www.jetbrains.net/jira/browse/IDEABKL-4823

'Find Usages' often takes minutes to complete
http://www.jetbrains.net/jira/browse/IDEABKL-4427

0
Comment actions Permalink

Was OS you're running? As the matter of fact concurrent usages search
was implemented quite a time ago.
The only problem is all the concurrency is switched off on Macs due to
magical native JVM lockup problem (reported to Apple).

Max

0
Comment actions Permalink

Find usages are run concurrently.
The only problem is that the algorithm is disk IO-bound, not CPU-bound, so
the perceived improvement is not ver noticable.

--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

"Alex" <no_reply@jetbrains.com> wrote in message
news:426611.1189582193225.JavaMail.itn@is.intellij.net...
>I was just thinking about that myself. Find Usages is currently not
>multithreaded. On a dual-core or quad-core machine running latest EAP, you
>will only see one cpu busy when you run Find Usages. (Also Find in Path).
>

Find Usages is probably the #1 candidate now for a multi-core makeover.
Try running Find Usages on a big class and check 'Usages of methods". It
takes minutes and minutes to complete.

>

There is an old Jira IDEABKL-260 filed already "Find usages support
multiple processors", but the priority is Minor. Well, the priority is
more like CRITICAL now because everybody has DUAL and QUAD core
workstations that are sitting around spinning their wheels while Find
Usages runs.

>

Selena EAP already has the big improvement in syntax/inspections parse
using multi cores. (I haven't quantified exact speedup but both my cpus
are maxxed out when I load a large Java file, so maybe it's close to 2X
speedup).

>

Jetbrains needs to keep making long running tasks multi-core ready,
because most developers at big companies now have DUAL core workstations,
and it won't be long before we're running QUAD core. AMD just came out
with their Barcelona Quad core chip
(http://www.tgdaily.com/content/view/33762/135/), and later this fall,
Intel is coming out will a bunch of 45nm QUAD core parts. The price is
dropping rapidly, and I'm expecting QUAD cores to be plentiful in 2008 for
engineering / graphics workstations.

>

I think if Jetbrains can fully harness a QUAD core workstation, then that
would help their reputation as the professional's choice for Java IDE
editor.

>
>

Find usages support multiple processors
http://www.jetbrains.net/jira/browse/IDEABKL-260

>

Use compiler caches to speed up Find Usages
http://www.jetbrains.net/jira/browse/IDEADEV-12010

>

Find Usages - Usages of Methods of a Class - Should do one search for each
group of overloaded methods in a class
http://www.jetbrains.net/jira/browse/IDEADEV-17409

>

Problem with finding usages on setName() and getName()
http://www.jetbrains.net/jira/browse/IDEABKL-4823

>

'Find Usages' often takes minutes to complete
http://www.jetbrains.net/jira/browse/IDEABKL-4427



0
Comment actions Permalink

Well, what do you know, Find Usages is multithreaded! I could have sworn it
was only using one cpu when I was using it last week, but now I just tried it
again, and when I did a "Find Usages" on a class with Usages checked and
Usages of methods checked, I was seeing 70-90% cpu utilization. (See attached
cpu chart. The chart shows two runs of the same find usages. The 2nd run was faster,
I guess because less I/O was required?)

This is on a DUAL core workstation running Windows XP SP2. I'm curious as to how this
works with a QUAD core workstation.

I guess you can mark IDEABKL-260 as Fixed. As I mentioned before, it would be real nice if you published some sample benchmarks show the speed improvement from IDEA 6.0 when using DUAL or QUAD core workstations.



Attachment(s):
7274_find_usages_methods_cpu_profile.png
0
Comment actions Permalink

I must be losing my mind, because I looked back in my post
history and saw I already brought up Find Usages performance in
Selena EAP back in Mar, 2007 when it became multithreaded.

6776 - Find Usages Performance
http://www.intellij.net/forums/thread.jspa?threadID=266456

Anyway, I'm happy to report that IDEA 7.0 is 25% faster than
IDEA 6.0.5. I repeated the test from that previous post where I
run Find Usages with Usages and Usages of methods
checked on a large class which is used 11,000+ usages in a large
project. I start IDEA, and then immediately navigate to the
class and do the Find Usages.

IDEA 6.0.5 7 min 48 sec (468 sec)
IDEA 7.0 EAP (7274) 5 min 56 sec (356 sec)

So IDEA 7.0 EAP 7274 is (1 - 356/468)*100.0 = 25% faster

0
Comment actions Permalink

Find usages are run concurrently.
The only problem is that the algorithm is disk IO-bound, not CPU-bound, so
the perceived improvement is not ver noticable.


Hi Alexey,

In a test I just ran, I am seeing 25% improvement in IDEA 7.0 EAP (7274)
versus IDEA 6.0.5. Granted, this is for one particular large Java class that
has 11,000 usages in a large project, so I don't know if the 25% improvement
will be seen in all cases, but it looks like I'm getting some benefit from
my DUAL cores on my workstation.

Are you working on that IDEADEV-17409,
"Find Usages - Usages of Methods of a Class - Should do one search for each group of overloaded methods in a class"
That one didn't seem too difficult to do, and would give me alot
of bang for the buck when doing find usages of methods on many
of my classes in my project.

As I mentioned in my old thread, the test class I was finding
usages on had many overloaded static methods like 8
different methods called load(...), 5 different create(...), etc.
and also there were 6 different constructors. It appears that
IDEA is not looking up all the overloaded methods at once but
one at a time because I would see multiple messages like "
Searching load...", "Searching load..." and these searches were
some of the longest.

I think if IDEADEV-17409 was fixed, then my test case would
finish in about half the time: 3 minutes vs the current 6 minutes.

-Alex

0

Please sign in to leave a comment.