I'm developing in Eclipse in Java and I noticed that the software execution in my eclipse is much slower (like 6 or 7 times) than the same code run in eclipse in another similar pc (both have 8gb ram 8 cores). The only difference is that I'm running on windows 7 and the other pc is running ubuntu 13.04.
I already checked and I'm using the right virtual machine (jre 1.7, the linux one is with jre 1.6) and there are at most about 20 prints on the console over a 6 minute run. Also I'm running as "run" and not debug.
What can it be? Is it possible that under linux is much faster?
UPDATE:
I installed a partition with Debian 7 on the same laptop with windows (where it was running slower). With both the default open jdk 1.6 and the new java 1.8 Debian is much faster. I would say ok if it was like 2 times slower, but a 6 minute execution instead of a 1 minute one is a bit strange.
Linux is in fact faster (usually) than Windows. It depends on alot of things though, RAM and cores are not only things that matter. CPU architecture, clock speed, OC or not and so on. If you´d post both computers specifications then it would be easier to answer but until then there's your answer.
One thing you can do is use a Terminal on each platform:
First do a java -version to make sure both are really using the Oracle JVM (for example, on Ubuntu, a trivial installation of Oracle JDK may not guaranee that you're not still using the original Open JDK).
Then, run your Java program in the terminal on each machine, and see if the difference persists. If it doesn't (i.e. if you only have the big performance gap when running from Eclipse), then it might be Eclipse's fault. While Java does tend to be faster on Linux/Debian vs. Windows, Eclipse might not have the same trend. If your experiment shows that Eclipse is the reason for the performance gap:
make sure that Eclipse is configured to use the Oracle JVM on each platform
make sure Eclipse itself and all it's possible plugins are updated (and if not, update first Eclipse, then its plugins).
Related
I have 4 GB of ram and a core 2 duo processor . I am running eclipse for android on it and its running slow. There are no other programs running on it and its only using 40% of the CPU.
I thought that if i could dedicate a CPU only to this program it might run faster. Any idea on how it can be achieved. Any help on this matter would be appreciated.
This problem also made me think on how a multi core processor runs and why is it better then other single core systems any verified literature on this available on web.
These are some general methods to speed up your eclipse,
1.Make sure you have latest JDK installed and eclipse has reference to it.
2.You are currently using Juno(4.2) , try to install latest version like Mars or Luna(4.4) . It is preferable to use Android Studio because it is official IDE for Android development.
3.As you have 4GB of RAM ,try to modify eclipse.ini file
-Xms128m
-Xmx350m
Replace -Xmx350m with -Xmx4G so that it gets 4 GB of RAM instead of 350MB .
There is noting magical to seed up your PC or eclipse. It seems that your CPU is not faster enough as your desire. And obviously eclipse is not very lightweight too. So there is no solution actually. And don't be frustrate by thinking that your PC or eclipse is doing something unusual. Its normal.
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
We use Java within our build process, as it is used to resolve/publish our dependencies via Ivy.
No problem, nor have we had with it for 2 years, until we've tried to upgrade Java 6 Update 26 to Version 7 Update 7, whereas a build on a local developer PC (WinXP) now takes 2 hours to complete, instead of 10 minutes!!
Nothing else has changed on the PC, making it the absolute target for our concerns.
Does anyone know of any reason as to why version 7 of Java would make such a speed difference like this?
UPDATE: The build process is NAnt-based, so Java.exe is called from a NAnt script, running in a Command (DOS) window.
I'm using JDK 7u7 and I noticed a better performance by tuning some VM Options.
You could try the G1GC and AgressiveOpts to help with compile time.
Follow the settings I use in my editor:
-Xss8m
-Xmn256m
-Xms512m
-Xmx1024m
-XX:PermSize=256m
-XX:MaxPermSize=512m
-XX:+UseG1GC
-XX:+OptimizeStringConcat
-XX:+UseStringCache
-XX:+AggressiveOpts
You will find each option's description in the VM Options link.
I hope it helps.
In my experience, Java 7 was a huge step backward in terms of speed and compatibility. I've found it slower not only to compile, but running the JRE as well.
I've also had major issues running eclipse with it (and yes, i've used update 7).
And from my standpoint there's nothing in Java 7 that i need. I like the ForkJoinPool, and can get that as an add on library for Java 6.
Maybe Java 8 will be better.
First, did you remove JDK6 or leave it in place? Check your JDK_HOME and any other place it is specified to ensure that you are actually using JDK7. In the XP console type java -version and ensure it is what is expected. (Close/reopen the command prompt to pick up changes in the Win GUI.)
It was never stated what version of XP you are running -- 64-bit or 32-bit. Ensure the appropriate JDK environment is on the machine. (Depending on exactly what is executing, this can make a tangible difference. Also, the best bet for debugging is to keep it the same as before -- reduce variables.)
Troubleshoot the issue and narrow it down. Does an Eclipse installation perform slower after the upgrade? (Eclipse itself runs in a JVM. It's a good baseline.) Is Eclipse pointing at the correct JDK when you test it? Try other Java tools to see if there is a performance difference. Breakpoints and logging at different control points in the build and any Java executables are your friends.
Since Nant is .NET based, have you looked at the Java process that is actually launched? Is your Ivy distribution really old?
All this said, it is hard for me to believe this is a Java issue and not a configuration challenge on the Windows box. Have you tried it on any other machines, anyway?
I'm on a team of 6 developers and we are all using Eclipse Indigo on Ubuntu 11.04. At least once a day, if Eclipse is running, each of us experiences a total system lock-up. The only cure is a hard reboot of the PC. Some of us have had it more than ten times in one day. This does not happen if Eclipse is not running, so I can confidently say that Eclipse is the problem.
I have tried increasing the memory available to Eclipse by going into the ecplise.ini and increasing the Permsize, MaxPermSize, Xms, and Xmx. This has made no difference and everyone's PC is still locking up.
Has anyone experienced this before? I could understand maybe on one PC, but it happens on every single PC!
Java version: java-6-sun-1.6.026 JDK version
Ecplise version: Indigo SR1 BuildID 20110916-0149
Ubuntu version: 11.04 64-bit
EDIT: Ctrl-Alt-FnX keys do not work once the PC has locked up.
EDIT: I've revisited the eclipse.ini settings and increase the memory some more. So far I haven't had a crash yet. I will use the other developers as guinea pigs, but I'm hopeful that these settings will stop the crashing.
-XX:PermSize=256m
-XX:MaxPermSize=512m
-Xms1024m
-Xmx2048m
This is not to resolve Eclipse problem... which might be happening because of some display issues I suspect.
Instead of hard reboot you can press keystrokes Ctrl+Alt+F1 together to reach console and there you can login to a text based terminal and kill the Eclipse process.
more a comment than an answer, but I cant add you a comment yet.
I'm kinda using the same setup: Ubuntu 11.04 64bit with Eclipse Indigo SR1 RC3 64-bit (buildid 20110909, didnt had time or need to update to a newer release yet, but RC3 is stable for me). Make sure, you have installed the 64-bit version of Eclipse.
OpenJDK in combination with Eclipse didnt went well for me, so I changed to java-sun jdk 1.6/7. Make sure Eclipse is not referencing to the OpenJDK installation instead of java-sun jdk.
I had some issues with Eclipse Indigo (pre SR1) freezing in combination with SVN Subversive/m2eclipse plugins. For me it got better with the SR1 (RC3), but still not perfect (a freeze now and then). A while later Subversive SVN had an update, and now it's stable again. In short: make sure, you have installed the newest plugin versions (use eclipse update sites, no local copies). Older versions might lead to the same problems I experienced.
What other plugins are you using, can you verify if your Eclipse crashes without any plugins installed?
Two other issues I'm aware of: with Ubuntu Karmic Koala (9.10) rendering UI elements was broken/lead to crashes as well (GTK_NATIVE_WINDOWS). Later Eclipse had problems with the native scrollbars (think it was with Ubuntu 10.10 or 11.04). I'm pretty sure, problem 1 aint an issue anymore with Eclipse Indigo + 11.04. Problem 2 I'm not sure if it was 10.10 or 11.04. But I still start my eclipse with the following script.sh and it works for me, you could give it a shot as well:
#!/bin/bash
export LIBOVERLAY_SCROLLBAR=0
export GDK_NATIVE_WINDOWS=false
exec $(dirname $0)/eclipse "$#"
Try upgrading the kernel to the latest version. I think this lock up is caused by the kernel bug detailed on this page https://bugs.launchpad.net/ubuntu/+source/linux/+bug/924905
While you wait for better answers, I would definitely try a virtual machine like Virtual Box to:
Try to see if I can replicate the problem in a Virtual environment, which is similar to your actual environment. This way you can see if the problem the combination of the versions of software that you're using or your physical hardware.
Run Eclipse through the VM. It may not crash and will prevent you from having to do a full re-boot of the system, until you determine what the actual problem is.
I have a similar problem. From time to time it happens that the complete X11 desktop freezes. I can still move the mouse but clicks on elements have no effect.
In this situation I switch to the text console and kill eclipse. After I did that, everything works again.
I am using a laptop with an Intel graphics chipset. So I tend to blame it on the the graphics driver.
I have other computers with different graphics hardware where I haven't noticed the problem, but I don't use eclipse that often on them. On all I am using Ubuntu 11.10 64bit with gnome or unity desktop.
I have the same issues. It is very inconvenient. I have just confirmed that killing eclipse fixes the issue for me.
However, I have found something strange in that I can still click on the stupid overlay scrollbars. It's like they have the focus of the entire system.
What seems to have fixed the issue to me was to install the gnome shell and start using gnome 3, then turn off the overlay scrollbars in the startup scripts for X. I installed gnome 3 for a separate reason and disabled the scrollbars because I find them annoying, but I do find that this has solved the problem for me. You may be able to get away with just disabling the scrollbars, information for which is readily available on google.
I had a windows vista machine with much lower specs and Netbeans6.8+Scala2.8 worked fine.
old specs: Vista home premium, 4 GB ram, 320 gb hdd 5400 rpm, java 1.6.0.16
new specs: Win 7 professional, 8 GB ram, 250 gb ssd, java 1.6.0.21
The compilation on the new machine is much slower. Java and javaw take up to 95% cpu during compile.
any ideas how this can be fixed?
I am not able to upgrade NB due to some restrictions.
All I can say is try to ask to see if you can get a newer version of Netbeans. Netbeans 6.9.1 has many performance improvements, with Netbeans Dev being faster. You can make an argument saying that the slow performance is impacting your work.
Really the only other things you can do is disable modules you don't need which might free up some resources.
With that much memory you could try to run NB on Vista or Linux in a VirtualBox instance.
Answering my own question since I found the cause:
The reason (don't know if it applies to other Netbeans versions apart from 6.8):
the new PC runs 64 bit Windows 7 and a 64 bit JDK (I forgot to mention this in my question)
the old PC rund 32 bit Vista and 32 bit JDK
Netbeans currently runs in 32 bit mode only, so when on the new PC, it was an issue with running the 64 bit JVM from Netbeans. This problem is discussed here:
Issues with running 64 bit JDK under Netbeans
The easiest solution for me was to install a 32 bit JDK and force Netbeans to use it as the default platform (required modifying netbeans.conf). Additionally, -J-Xmx512m
did not work on the 32-bit JDK, so I had to set it to -J-Xmx400m
The following stackoverflow link was also helpful in figuring out the optimal settings:
Netbeans config options for optimal performance