I have this problem with eclipse Mars.2
Build Automatically is disabled and nothing is in progress.
Each time I start eclipse, there is a high CPU usage. Here is what JProfiler says:
Eclipse seems to be compiling something, by why?
Another strange thing is that if I try to quit Eclipse, the process does not terminate.
Thanks
Are you working on Javascript files using Eclipse JavaScript Editor? - Seems to be it's indexing javascript files (JSDT - JavaScript development tools) during the eclipse startup, usually indexing will take some amount of time to parse the files,index the functions and variables for content assist/proposals purpose.
Related
I'm trying to use VisualVM with IntelliJ to profile a Java application. I have the VisualVM Launcher plugin installed inside of IntelliJ. I press the play button with the orange circle in IntelliJ that launches VisualVM and opens the process when I start the run. However, when I try to profile the CPU, it doesn't seem to profile the methods in my program. I've tried with several different programs and can't seem to get any of them to work with VisualVM. This is what VisualVM looks like this:
The profiler seems to think that the total time is 857 ms or 6.21 ms when in reality my program takes about a minute to run. It seems to be capturing "DestroyJavaVM" which is not my program. I'm using VisualVM because it is the only free Java profiler I could find. Any suggestions? Here are my VisualVM settings:
As others have suggested, take a look at your "Start profiling from class" setting.
But you might want to consider it being a timing issue. As you can see in the background, the process you want to debug is already finished.
Check in the call tree and in the list of processes to the left what you are debugging. In your screenshot you are debugging the destruction of the JVM. That does not include your code, so you should not see it there.
I'm using IntelliJ IDEA 10.0 for Java development. A few days ago it started to reveal a strange behavior with auto-completion: pop-ups with completion options appears as usual,
but IDEA completely freezes after choosing an option.
Cache cleaning doesn't help.
Has anyone else encountered this?
Update: Another symptom: IDEA freezes when trying to auto-implement method (e.g. toString)
This is may be due to garbage collector working hard.
Try give your IDE more memory. You can do it in idea.exe.vmoptions(if you use windows). Increase -xmx property to at least 512 MB.
This may not be the same issue you describe, but I have experienced long (but not eternal) freezes, where after a minute or two it came back to respond. This happened whenever I pressed Ctrl+Alt+Space in the code completion popup, which caused IDEA to load all project and external libraries to browse for possible completion options.
I have Eclipse Helios SR1 installed on Windows XP. I am writing/debugging Java code using JDK 1.6.
When I debug and I hit a breakpoint, Eclipse is fast to show me the stacktrace. (See #1 in attached image.)
However, the source code line highlight (light green, see #2 in attached image) is very slow to appear. Oddly, when I first installed Eclipse, this was very fast. Now it is very slow. It takes about 15 seconds to highlight as light green.
Any ideas what is wrong with my Eclipse install/config?
FYI: Very fast processor + 4GB of RAM. Plenty of disk space. I have tried a "Hello, World" test Java project. Just a few lines of code... still the same issue when hitting a vanilla breakpoint.
According to running-a-program-in-debug-mode-is-incredible-slow I succeeded with running
eclipse -clean
(test this before you setup a new workspace)
This is surely not an Eclipse problem. If it is highlighting, means its working.
There must be something wrong with the Windows. More RAM does not mean necessarily fast processing. Check Task Manager, and try to monitor processes, especially the java one. There can be multiple
java processes, kill unnecessary ones.
If the laptop using some sort of disk encryption, then this is surely possible.
If your anti-virus is hogging the CPU, quite possible.
Or else you can do one more thing is that everyday you can manually clean your project and you can also set the console limit to unlimited.
The answer is simple: Create a new workspace.
I did it and now my debugger is super-fast again.
The auto complete stalls so frequently and for so long, I quit using it altogether.
I've had success with the following using Eclipse (Classic) 3.6.1 on Windows 7 x64.
"A workaround, until the fix is released in 3.6.2 is summarized here: http://groups.google.com/group/android-developers/msg/0f9d2a852e661cba"
(copied for convenience)
"You can replace your /plugins/
org.eclipse.jdt.core_3.6.1.v_A68_R36x.jar plugin with one from
http://www.google.com/url?q=http://adt-addons.googlecode.com/svn/patches/org.eclipse.jdt.core_3.6.1.v_A68_R36x.zip&ei=vg5aTf2RIMrUgAeI-qTvDA&sa=X&oi=unauthorizedredirect&ct=targetlink&ust=1297749446528273&usg=AFQjCNFv7FGlTrnoVhRGE35JPjHxOwI_Bw
and restart Eclipse. Content Assists will be much better. Just try it.
Don't forget backup your original plugins. "
This solved part of my problem.
In preferences, I defaulted all the 'Java->Editor->Content assist' screens and the performance is much improved. Any lag I have now is due to system speed and is negligible. I've gone from minutes to seconds building the suggestion list.
UPDATE: This didn't completely solve my problem, but it got me close. The search continues...
UPDATE: I'm developing in Java for Android using the default packages that are included and any that might have come down during a update(in retrospect, maybe choosing update all in the SDk update might not have been wise). The timing is fairly consistent online and offline. I did a few tests and found the following:
Startup Eclipse and enter a line of code that can use a .toString(). Typing the '.' populates the auto complete within 2-3 seconds. Type a 't' and it takes 70-75 seconds. After that, 10 seconds. Diff objects do the same thing(75 the first time, 10 after that). It's the filtering process that appears to stall. My CPU does not max, Memory is OK, but the program will go not responding till it's done. Any typeahead gets cached and eventually filters the list when Eclipse starts responding.
For me the problem went away when I increased the memory for the vm.
Put this in your eclipse.ini:
-Xms512m
-Xmx1024m
on my 4GB Windows Vista system this would happen A LOT !! (as well as debug issues when looking up variables).
This all went away after I built my new PC with 8GB RAM. I can now run 4 emulators simultaneously and it doesn't have any debug problems any more either. Auto complete with huge lists also works just fine.
it would seem to be just an issue with how much RAM you've got.
[UPDATE: I forgot to add that this 30 sec. freezing problem only happens the first time I try to load a file from the server. Subsequent loads are very quick. Maybe some strange reverse DNS lookup? I am hosting on Google's appengine.]
I started a little project recently called http://www.chartle.net which is build around an applet.
Startup time is an important factor in the user's experience of an applet. I collect statistics and am shocked that I find often very long startup times (factor 50 to 100 higher then necessary)
The applet starts in 1-3 seconds depending on the speed of your computer and connection. Still for some users it takes up to 100 sec.
I have mixed results from my own tests. Mostly it is very fast but sometimes freezes the browser for a long time and the Java console doesn't tell me why. Best guess is, that it stalls when loading a saved chart.
Please help me figuring this out - best test by opening an already saved chart (click on one of the 'create' links at http://www.chartle.net/gallery)
Cheers,
Dieter
This is generic help rather than specific for your demo (which loaded fine for me in a few attempts).
Freezing applets
In the JDK bin directory there is a very handy programme called jstack. Refresh your browser window until it crashes and then run:
jstack *process_id*
This will give you the stack trace of any frozen Java process. If Java is not a separate process then you can use the browser's process (eg for Opera).
The following few problems were/are common for me:
I reccommend you use invokeLater rather than invokeAndWait on the init method (although you can't do this if you use start/stop methods)
Opera's custom java plugin acts very poorly...
Deadlocks caused by synch blocks and invokeAndWait's
Slow applets
Possibly the browser is fetching resources from the server, unable to use the jar file?
It may be that only the old plugin causes these problems. That means basically all people running on OSX and other users with Java prior to 1.6_update_10.
So, I would really appreciate people with such setups to watch their Java console and describe the first startup behaviour.
Cheers,
Dieter