I've just changed computers at work and now have a really beefy 64bit Vista os. Currently I'm still slogging through the pile of quirks (like no 64bit drivers for ms access) and I've noticed that my startup time for eclipse is a LOT longer than it was on 32bit Vista. I have almost nothing in my workspace yet, so that knocks out most of the change/rebuild workspace issues. I've used the -clean option a few times and nothing seems to change it.
I'm not running the 64bit version of eclipse, just because it seemed like too much trouble right now with all my other issues getting the machine back into a stable state. It also seems like 64bit eclipse is still pretty rough around the edges since it doesn't appear to have actually been released yet.
Any clues about what I can try to speed things up? Once it's running, it seems to work fine.
TIA
Try tweaking the JVM's memory settings. E.g., if you have 512 MB memory, pass "-vmargs -Xms40m -Xmx256m" to eclipse.exe.
You may give eclipse 64bits a shot (even though you say in your question not using it).
With the latest JDK (6u12) and the latest 3.5M5 eclipse, it does work quite fine.
With my settings, that is ;)
Related
I have had the same problem with both Oxygen and Photon latest releases on Ubuntu 18.04LTS with java version "1.8.0_151".
I am debugging a Swing application. After reaching an enabled break-point, the entire Ubuntu GUI "hangs". Mouse clicks on an icon which start other applications and the eclipse window are totally ignored. The only recovery is to reboot the computer.
The strange thing is this appears "intermittently". It will work fine for long periods of time and the other times it occurs. It is in one of the "it always occurs" times.
.
I don't recall experiencing this with non-GUI applications.
Any thoughts on how to fix/workaround this?
TIA,
Roy
I was also facing the same issue. I would suggest to check your OS, if it is 32 bit downgrading your eclipse to Oxygen package seems to be the only choice available. Else you can upgrade your OS to 64 bit if supported by processor if you wish to carry forward with Photon package of eclipse. Support by eclipse on 32 bit OS is no longer available.
I am running a Fedora 24 OS (with GNOME 3) and I just installed the eclipse CDT package from the Fedora repositories (Eclipse CDT Neon.1), and it turned out to be extremely slow, but only when writing code or scrolling, the rest of the UI works perfectly and really quickly.
I have done some research about the topic and seemingly this problem is usually related to the GTK backend, and is commonly solved by running eclipse under GTK2 instead of GTK3. However, this has not helped me at all. The options I have tried are:
export SWT_GTK3=0
And
eclipse --launcher.GTK_version 2 (also tried in eclipse.ini)
These two options effectively switch to GTK2, which is noticeable because the graphical appearance changes.
I tried also older versions of Eclipse (Juno, Kepler and Luna) and the problem still exists, probably even worse. I have increased the memory size for the JVM to 3GB and the problem remains intact.
The underlying hardware is a 6 core Intel Xeon (12 virtual cores with Hyperthreading) and 32 GB of RAM, so I assume this should not represent a problem.
I also noticed that while scrolling or writing, one of my cores goes to 70%-100% utilization, which explains the lag, but I don't know how to solve.
Is there any other option I can try?
Yes, I know. I got no rep on this site. But I have to ask this.
I upgraded my laptop, my main dev machine, from 14.02 LTS to 14.04 LTS and the plugins I use with eclipse (3.7) completely broke. I use WOLips (https://github.com/wocommunity/wolips) with eclipse. WOLips is for working with WebObjects applications.
I was getting two crashes. One would occur when editing a java file, when auto-suggest kicked in. I fixed this by adding "-Dorg.eclipse.swt.browser.DefaultType=mozilla" to the end of my eclipse.ini. I have no idea how I found that. It took a lot of random searching.
Now, I get an exception whenever I open a WOComponent:
Unhandled event loop exception
No more handles [Could not detect registered XULRunner to use]
Trying to define a XULRunnerPath just gives me even stranger errors.
I can file a bug with eclipse (which I did). I tried eclipse 4.2 and 4.4 and got other complicated integration issues. I can file a bug with mozilla (though I was not aware that they were involved). I can install a copy of xulrunner (outside of my copy of Firefox) and point to that (which I did). I can file a bug with ubuntu launchpad (which I did). None of these get you very much response.
So, I was going from one LTS to another LTS. 14.04 - 14.02 = 0.02. Not a huge deal, yes? Should I have expected problems? How can I file a bug with the people involved in just this upgrade and not the other twelve systems that this touches upon?
I had Apple laptops for a long time. I do not expect that amount of hand-holding. But I do wish someone would throw me a bone.
I can get work done if I go buy another hard disk, install 12.04 onto it and copy all of my data back. Is this really necessary? You know, I am willing to help integration testing of these releases. But the systems for finding the right place to put my oar in the water seem fairly impenetrable. Any suggestions? I do not mind working for a solution. If there is a solution.
Ray,
Did you try Eclipse 4.4 and use the instructions on the wiki for compiling the new WOLips? the Eclipse 4.4 is acting just fine for me (but I'm on a Mac sorry :( )
An infuriating problem.
My Netbeans IDE 7.2 refuses to shutdown when I try to shutdown my machine.
I have got to use task manager to close the beast.
Its a windows 7 64 bit machine.
I have tried the usual Netbeans forums.
Any Ideas?
PS: I also use the well behaved Eclipse.
from what I'm seeing, you might have a corrupted install of netbeans cause usually it is light on a system. How long ago did you install it? Did you make any major changes before this all started, from evinvorment setting changes to major changes like how the thing complies etc...? I would say, the easiest bet is to back up the settings, if possible, and reinstall or do a repair install, if offered, of netbeans.
Upgraded to 7.3 and I no longer have a problem.
BTW Netbeans 7.3 is great for developing HTML 5 code.
This might be a dumb/naive question, and if it is please excuse me :)
I have a brand new machine with the following specs:
Inter Core i7 2600#3.4GHz
RAM 8 GB
Windows 7
This machine has a 64 bits architecture.
On my previous machine, I used to install 32 bits versions of Eclipse and run it using a 32 bits JRE, and my current Eclipse setup works perfectly on the new machine.
I tried to install a 64bits version of Eclipse, and run it with a 64 bits JRE, and I am wondering if there are any compelling reasons to switch to this kind of setup or stick to my existing install. I guess that I would have to reinstall all the plugins, and maybe find that some of them are not compatible with the 64 bits version of Eclipse.
So far, the 64 bits version seems to need quite some more RAM than the 32 bits version, which is something that I expected, but nothing seems to have improved.
Thanks for your advice!
In general I use 64-bit Eclipse without problem, but there can be issues around plug-ins such as:
Adobe Flash Builder only works with 32-bit
The Subversion plug-in Subclipse needs a native 64-bit version of Subversion installed separately
There may be more but those are the ones I've encountered in the past.
Moving to 64-bit gives you access to more addressable memory but it won't speed anything up, in fact it might reduce performance in some cases (but nothing I see as significant to what I do).
Well the only thing that will improve is that you are able to use the advantages of 64bit. Other then that I'm not aware of any improvement.
For example what's better in 64bit is that if you have a very large project set you would be able to handle it more comfortably. For more information on 64-bit please look here
If you want to be on the edge of technology your choice would of course be the 64bit setup.
About the ram, this is expected because some of the Datatyps now use 64bit and are therefore larger to store in memory.
For most plugins you will get a 64bit version or alternative and so far for what I've used it it always worked.