I installed Eclipse Galileo and after trouble with the JDK, its starting well. But I have big problems with performance. Every third second, Eclipse is hanging for a while. It runs not smoothly. I need a efficient IDE as Eclipse for work. So, it would be very nice when you have a fast answer :)
Both Eclipse as the JDK are 64-bit versions.
Have you any ideas?
Update:
I can´t really explain the problem from scratch. But in my case, it was a trouble between Eclipse´s and the auto-complete-function of my OSK. If I disabled auto-complete, there was no hangs anymore. I don't know why the using of the OSK blocks the thread (?) of the whole editor.
Maybe anyone of you, has an idea why?
From your description it sounds like the garbage collector is being triggered. How much RAM have you got in the system? Depending on the plugins you're loading Eclipse can need quite a lot of it. I think the bare minimum is 256 Mb, and realistically you need at least 1 Gb, more if you're doing web development
Have you got an up-to-date JVM? Eclipse generally runs much quicker with a 1.6 JVM.
One other thing to check, do you have an aggressive virus scanner? Eclipse plugins are collections of small files in jars, some virus scanners can really slow down the performance. If you are able, remove the Eclipse install directory from the scanned files.
See this EclipseZone article or this question for some general performance tips.
Run Process Monitor and see what kind of system calls and/or file system calls the JVM is doing. Use filters aggressively to pinpoint a specific process. I had a similar issue where a graphics card utility triggered a flood of registry lookups for every UI update which just made Eclipse incredibly slow. (Somehow SWT was hit exceptionally hard by this bug, I'm not sure why.)
EDIT: I meant "Process Monitor", not "Process Explorer". But the link was correct.
You could try to run it from within a virtual machine set up on your computer to see if the problem is still there. If it's not, it might be faster for you to just work from within the virtual machine environment. Doesn't address the issue, but it may help avoid it altogether.
I had same problem so I just switched to the 32 bit version of Eclipse and it runs fine with no performance issues.
I can´t really explain the problem from scratch. But in my case, it was a trouble between Eclipse´s and the auto-complete-function of my OSK. If I disabled auto-complete, there was no hangs anymore. I don´t know why the using of the OSK blocks the thread (?) of the whole editor.
Maybe anyone of you, has an idea why?
Thanks for any help!
Same problem for me
I have Windows 7 professional 64 bit and 8gb of RAM
Eclipse is extremely slow, probably 5 times slower than the Windows Vista 32 bit machine I have recently upgraded from (Europa version) - and that machine was a complete dog!
Adding -Xmx1024m -XX:+UseParallelGC -vm C:\Program Files\Java\jdk1.6.0_20\jre\bin\server\jvm.dll has made a pretty big difference
I have same problem as not respoinding.
I searched in internet for a solution. I found one by adding the below to
eclipse helios config file.
-vm
C:\Program Files\Java\jre7\bin\javaw.exe
Initially it looks Ok to start and click on the different buttons and
running on several files in eclips project. But when I click on debug
and step by step process. Then it is again showing not respoding.
I have a new laptop win7 installed.
I have the same problems with the 32 bit version, running with a 32 bit JVM.
It's more that my RCP Application which I developed with Eclipse is slow. I've tried both -Xmx1024m and -XX:+UseParallelGC, with no noticable effect. Has this issue been registed with eclipse.org?
Related
Since some years ago I started using Qt in both Windows 7 as well as in Linux Ubuntu and it would always compile fast with MinGW being used for Windows. But in the last couple of years or so, maybe thanks to updates in the version of both Qt and MinGW, I started detecting a slow down in the compiling speed inside Windows. I did some research trying to find why MinGW had started to become so slow compared to Linux (it wasn't before!) and everything people told me was that MinGW was slower in Windows and that it would be better, if possible, to just use Linux.
Since I wanted to continue my project, I followed the suggestion and since I've being using Linux with relatively no problems. The situation now is that I must go back to Windows (now updated to Windows 10) to make visual corrections for this OS and I need to once again work with MinGW having to face the same problem as before.
But for some reason it seems that the slowness of MinGW became even worse! While before I at least was able to compile the app in around 4 minutes, now the last time I tried it took 38 minutes before I gave up and went to sleep - and this is for a project that takes only 1:03 minute to be compiled in Linux [under the same compile configuration]!
Well I'm still aware about the slowness of MinGW, but as a quick research around this problem on the web reveals, that is just too slow: all backtesting one can find in other threads here on SO reveals at best 2x-3x more time to compile a project, not 38x+!!
So I would like to know what kind of possible problems I might have in my Windows for this exaggerated slowness to happen. I know I ended up installing at least 4 different versions of MinGW; could this have brought the problem?
It's interesting also to notice that when compiling using the -j option and watching the Compile Output log in Qt Creator alongside Process Explorer, there are moments when the compiling simple pauses for 10 seconds or more and the CPU usage drops from its ~100% to close to 5% with nothing happening till it suddenly continues the compilation process. I'm sure this constant pauses are part of the above average time, but I have no idea why MinGW is showing this behaviour.
You might want to check where the time is spent.
There a lot of tools that allow you to capture what a certain process is doing, I name just two of them:
ProcMon
XPerf or its successor
But to analyze the reports generated by these tools you need a rather deep understanding. If this doesn't help temporarily disable other running services and program step-by-step (if you want to know which program causes the problem) or disable all of them at once.
Looking at the spikes of cpu usage that TaskManager or Procexp by sysinternals show might help too to identify those components that block your cpu.
If your antivirus is the cause of the collision that makes the compile so slow you can define exceptions, then the antivirus will not scan certain programs or paths.
So perhaps it is easier to first try the compilation process with a disabled antivirus software or even from a clean live boot Windows CD.
I have a GCC 3.4.3 toolchain built for ARM (arm-elf) here in my Windows 7 (64bits) setup. We use this to build our software product to a specific hardware.
Recently, we have been experiencing some problems with this particular toolchain.
First, when we try to call arm-elf-gcc to build each source file (there are lots of them), it complained about it not being able to allocate enough heap.
Then, I thought it was some problem with the outdated cygwin DLL distributed by the hardware vendor. So I replaced it with a more recent version (1.7.35). The problem stopped and the build does go ok but now it is incredibly SLOW (it took about 40s to build a single .c source file).
Does anyone has experienced this problem before? How can I debug and fix it?
Thanks in advance.
Sounds like you have had a similar problem to me and might be worth trying this. When i first encountered this, I had to install cygserver and then run this (make sure you right click admin):
Previous solution
However, the problem resumed and I simultaneously couldn't install/uninstall some problems. Eventually I resolved this by terminating SearchIndexer.exe in Task Manager. Indeed, I have gone in to Control Panel / Searach Indexing and pulled it back from doing any indexing. My installation taking 1hr took 3 more seconds. The change to Cygwin was instantaneous.
Cygwin is now flying!
I've had an issue with slow execution of builds for a while on cygwin, using make and a proprietary compiler that "isn't gcc, honest...", but has very similar error returns.
I was forced to update yesterday and ran into the issue of rebaseall simply failing to execute. This forced me to dig into other things and I found a report that Trusteer Rapport/End Point Protection has been known to cause issues with rebaseall,and slow response times. So I removed it. This fixed the rebaseall, but has also massively increased the speed of my build. Worth checking to see if you have it installed, try removing it. AV packages in general are reputed to interfere and may be the cause.
Im using ReSharper 6 in a Vs 2010 Pro environment and are doing some pretty large scale projects. Development box includes 2 x quadcore xeon with 24 GB ram. Project's are running on a PCI-E x4 SSD drive with 1GB/s read and write (for real). So, i suppose there is not much I can do to give the development machine more power.
The worst project is an Umbraco site with roughly 14000 files and folders and some pretty nasty css. I got everything from second long freezes to 30 sec VS freezout.
I've optimized VS2010 according to every guide available in VS optimization. Even enabled the 64bit memory enhancement but the problems continue.
I've even added the media library folder to the skip list.
Are there any other magic tricks someone would know of, please let me know!
gorohoroh's comment lead me to the solution, the 6.1 nightly dec 13 rocks!
Thanks
http://confluence.jetbrains.net/display/ReSharper/ReSharper+6.1+Nightly+Builds
I am using 7.0.1 and I find that it's killing my machine too.
However, it normally happens if I have more than one VS2010 open.
If it happens then the only way of fixing it I have found is to close VS, delete the DotSettings.user and the suo, and then reopen.
I'm using 6.1, and find that it slows down over time, and typing becomes really laggy. I've just discovered that when it starts to chug, if I go to "Tools..Options..ReSharper..General", then click on Suspend, then Resume - it goes back to it's initial speed.
I have some customers/candidate who complained that my program doesn't work on their Windows 7 64 bit version (confirmed with screenshots). The errors were strange, for example:
in the trial version i am
getting a error message whenever i
click on \"mark\" \"delete\" \"help\".
error msg is: Access violation at
address 0046C978 in module
\'ideduper.exe.\' read of address
00000004
windows 7 ultimate 64bit. i7 920
#2.67GHz 9gb or ram
'Mark', 'delete' and 'help' are just standard TToolButton on TToolbar.
The other example is failing to get a thumbnail from IExtractImage.
I have told them to try Compatibility mode but still doesn't work.
The problem is when I tested it on Windows 7 HP 64-bit on my computer (which I've done it before released it actually) it just works fine! So I don't know what causing it
Do you have any advice ?Are different Windows package (home basic,premium,ultimate,etc) treating 32 bit prog differently ?Are the newer version of Delphis (I use 2006) more compatible with 64 bit Windows ? Do I need to wait until 64 bit compiler out?
Thanks in advance
Your best bet in my opinion is to add MadExcept or EurekaLog or something similar to your application and give it to the customer to try again. MadExcept will generate log with stack trace, which will give you a clearer view of what is happening there.
To answer 2nd part of the question, 32bit Delphi programs work fine on 64bit Windows 7. I think it's more likely you have some memory management problems and the customer just happens to stumble upon them while you don't. Use FastMM4 to track those down.
Your applications is trying to access an invalid pointer. Changing environment may surface issues that are hidden in others. Check your application, and use FastMM + JCL+JCVL/MadExcept/EurekaLog to get a detailed trace of the issue. Some Windows APIs may have some stricter call requisites under 7 and/or 64 bit, but we would have to know what your app actually cals.
A free alternative to MadExcept is JCL Debug stuff. However it is less thorough and doesn't include the cool dialog box to send the stack trace to you via email, or as a file you can attach and manually email.
MadExcept is worth the money, and it is free for non-commercial use. You could try it first on your own PC, observe its functionality, and be sure it functions the way you want, and then buy it.
If buying Delphi is worth it (and it is!) then buying mad Except is a no brainer. But if you insist on rolling your own, JCLDebug (part of jedi code library) is also pretty nice.
Give them a stripped down version of your app and see when the problem goes away. I am betting it is your code as I never had any problems with my (hundreds of) W7/64 clients.
I'd be willing to bet it's an issue in your code. The reason it's failing on your customer's machine and not yours is that your machine probably has the default Data Execution Protection (DEP) enabled (which is turned on only for essential Windows programs and services), while your customer's computer is actually using DEP as intended (turned on for all programs and services).
The default setting (which is compatible with older versions of Windows, like 95/98/ME), allows software to execute code from what should be data segments. The more strict setting won't allow this, and raises a system-level exception instead.
You can check the settings between the two by looking at System Properties. I'm not at a Win7 machine right now, but on WinXP you get there by right-clicking on My Computer, choosing Properties, clicking on Performance Options, and then selecting the "Data Execution Prevention" tab. Find it on Vista/Win7 by using the Help; search for Data Execution Protection.
The solution, as previous answers have told you, is to install MadExcept or EurekaLog. You can also get a free version as part of JEDI, in JCLDebug IIRC. I haven't used it, so I can't vouch for it personally. I've heard it's pretty good, though.
If you don't want to go that route, set a breakpoint somewhere in the startup portion of your app (make sure to build with debugging info turned on). Run your app until the breakpoint is hit, and then use the IDE's Search->Goto Address (which is disabled until the breakpoint is hit). Enter the address from the exception dialog (not the one that's almost all zeros, but the 0046C978 address, prefixed with $ to indicate it's in hex) as in $0046C978. You'll probably end up in the CPU window looking at assembly code, but you can usually pick out a line of Delphi code of some sort that can sometimes give you a place to start looking.
In addition to all previous suggestions, I'll add the difference in accessing Registry under WOW64 compared to Win32. If your application is accessing Registry to read or write some settings, you should be aware of this. First, take a look at this and this page in the MSDN. On this page you will find 2 flags that determine the access you get to Registry from 32- or 64-bit application. KEY_WOW64_64KEY is the one that you should use.
In any case, I agree with others about using madExcept (or any other similar tool) to be able to find the exact cause of your problems.
I'm getting out of memory issues when I'm running IntelliJ IDEA 9.0.4, build IU-95.627.
My Macbook Pro has 4GB of Memory
I've heard one recommendation clearing out the ~/Library/Caches/IntelliJ90 folder is an answer..
Is that something others would recommend?
What should I set it to?
I saw this post and tried setting EXE4J_JAVA_HOME in my ~/.profile but that did't make a difference.
I've heard others say setting this too high is not a good idea as well..
Any ideas?
IntelliJ Contents/info.plist VMOptions setting:
-Xms64m -Xmx512m -XX:MaxPermSize=128m -ea -Xbootclasspath/a:../lib/boot.jar
PS: Just in case this has any bearing on things, I've been trying to use Sqlprofiler at the same time with a Grails app using the p6spy plugin in my IDE.
I usually increase -Xmx to 800m
-Xmx800m
No other changes. I don't have any problems with that in any of my projects, some of them Grails projects. Lately I have followed the EAP versions, and now I use IDEA X.
(I also have a MacBook Pro, three years old, but with 6GB RAM)
I figured out this was down to looking up a huge stacktrace.log file in the target folder.
I didn't realise how huge it was until I looked at it in the Finder window....