Whenever I type any single letter, Android Studio tries to seek suggestion of methods and classes, and this freezes program. Even though I wait, it doesn't show any suggestions at the end whether I try to type proper method/class name or not.
I tried to check CPU usage first because whenever I try to type letters, CPU usage suddenly jumps up to about 90% from 0~10%. I took screenshot of Activity Monitor, and total CPU usage keeps exceeding 100 whenever I try to type single letter
Plugin Kotlin takes ridiculously high CPU usage only for trying to seek suggestions. There are about 300 classes including both Java and Kotlin classes.
I set IDE max heap size as 8GB because I have 16GB RAM
I'm using Android Studio 4.2 Beta 2 version
Invalidating/Restarting caches didn't work. Removing .idea folder in Android project folder also didn't work.
Is there any reason for this problem? and can I solve this problem?
It turned out that some class was causing problem, this class is java with generics. T in generic requires to extend Enum and implement my other class, this seems to cause Android Studio freeze. I'm trying to find a way to reproduce, but solved it by creating static java method which handles my codes. Only Kotlin is causing freezings.
Related
With one project open the IDE runs smoothly but once I open two the IDE runs painfully slow. I'm suspecting a memory issue.
I'm running an i7 2015 mbp with 16gb of memory. How can I up the amount of resources android studio is allowed to use to the point where two projects open won't lag?
I've already updated -xmx=2048 -XX:MaxPermSize=512m via Why Android Studio is slowing down when editing xml file or changing the design?
studio.vmoptions
-Xms256m
-Xmx2048m
-XX:MaxPermSize=512m
-XX:ReservedCodeCacheSize=225m
-XX:+UseCompressedOops
Modifying the properties the way I did is the first step.
The second step is not to touch Android Studio AT ALL until it is done processing. If you wait for all processes to complete (roughly 20 seconds) then it runs like it is supposed to.
It seems as though Android Studio's performance slows if you try using it when ANY processing is going on ie. if you wait for the first 20 seconds you're good to go but if it starts processing again for any other reason you have to wait until it's finished or you'll make the app lag quite badly for an indefinite period of time. This sounds like a bug that has nothing to do with memory available. In the meantime we'll just have to skirt around it...
** EDIT **
It seems as though the performance slowly crawls back if you lose it. Almost like a slow garbage collection. Restarting Android Studio when performance is poor is the only "fast track" I've found to getting around this bug.
I'm running AS 1.2.2. on OSX 10.10.3 The CPU usage swings wildly up and down. Trying to edit anything is a real pain - deleting characters, typing, type-checking - all are slow because Studio is consuming a huge amount of resources. I can press a key and must wait sometimes 5 seconds before it updates on the screen
Anyone else has this problem and figure out how to make Android Studio usable again.
Anyone knows what's the deal with this IDE?
I have been running it for a while, lately it has become very slow and unresponsive at times.
Gobbles up CPU even when just editing a bunch of js files.
Possibilities:
1. My code base is getting bigger...
2. I have several listeners which compile coffeescript and sass files in the background when these change.
In any case, I am very surprised (for the worse) that this is so slow. Would expect better from a developer of an IDE.
Anyone had this kind of problem before?
10x
There are a couple performance tweaks you can apply to Webstorm to see if it improves your situation. When my colleagues and I found that Webstorm was slowing down these tweaks solved all our problems.
First things first, ensure your project is configured to utilise webstorm resources efficiently by excluding particular directories from a project. This will ensure the containing files are not indexed in memory and will not decrease performance when performing functions such as searching for files or text within files. Some examples of good candidates to exclude are the node_modules directory and compiled code directories.
If there are still performance issues, try the following:
If you are on Windows by default you would be using the 32-bit version. Navigate to the Webstorm directory (within program files) and you'll see webstorm64.exe, which will run Webstorm in 64-bit mode. (You might need to install a proper 64-bits JDK yourself then.)
The default VM options for IntelliJ IDEA may be not optimal when your project contains more than 10000 classes and developers often try to change the default options to minimize IntelliJ IDEA hangtime.
You can try bumping up the JVM memory limits for Webstorm. Open the VM options from the IDE_HOME\bin\<product>[bits][.exe].vmoptions. Initially try doubling the Xms and Xmxmemory values.
Please note that very big Xmx and Xms values are not so good. In this case, GarbageCollector has to work with a big part of memory at a time and causes considerable hang-ups.
For more info on configuring JVM memory options you can refer to:
Configuring IntelliJ IDEA VM options - http://blog.jetbrains.com/idea/2006/04/configuring-intellij-idea-vm-options/
Configuring JVM options and platform properties - https://intellij-support.jetbrains.com/entries/23395793-Configuring-JVM-options-and-platform-properties
You can now do it from UI.
These are my before-after. No problems with the garbage collector. Just multiplied all values by 4. Machine: 20Gb RAM, 4Ghz i7 CPU & SSD disk. With defaults it started to lag. Now no lag again.
Pasting as text for quick copy:
# custom WebStorm VM options
# Default:
# -Xms128m
# -Xmx750m
# -XX:ReservedCodeCacheSize=240m
# -XX:+UseCompressedOops
-Xms512m
-Xmx3000m
-XX:ReservedCodeCacheSize=960m
-XX:+UseCompressedOops
I was dealing with a similar situation. CPU used to spike like crazy, and the IDE used to lag. Go to WebStorm preference and try disabling plugins that you do not need.
For instance, if your project uses SASS, what's the point of having LESS plugin running? Likewise, if your project uses Git, you don't need to have CVS or Perforce Integration.
CPU still spikes when WebStorm is indexing my project files, but I usually just wait it out.
Stopping my TypeScript file watching significantly helped (both in the IDE settings menu and in tsconfig.json). I assume that once the project gets big enough, any changes force a large recompile. It's not ideal but it's something that worked for me and may work for others as well.
When I test my app directly on the device, it crashes because I'm attempting to JIT-compile a method. I know why these crashes occur, I'm just trying to make them appear when I'm testing on the simulator instead. It's much easier than deploying to a device every time (it also takes less time).
I tried adding --aot-only to the mtouch arguments but I get the "Unknown command line argument" error.
No, there's no AOT compiler shipped for x86.
Now even if there was one it would:
a) become a lot slower to build. In fact it would be similar to building for devices. The only time saved would be for deployment (which is not the largest part of the build/deploy time);
b) still give you different results than iOS devices. The iOS simulator is, in many ways, different than iOS devices so testing on devices is very important.
Notes:
A lot of the JIT exceptions are related to the use of value-types inside generics. This is being, in large part, fixed in the 6.3.x releases (beta);
There are tricks to make your device builds faster. You can find some here in stackoverflow and (soon) the video about my Evolve 2013 presentation should be available.
Some days ago I set up my computer and installed a new copy of Windows 8 because of some hardware changes. Among others I changed the video card from Radeon HD 7870 to Nvidia GTX 660.
After setting up Visual Studio 11 again, I downloaded my last OpenGL project from Github and rebuilt the whole project. I ran the application out of Visual Studio and it crashed because of nvoglv32.dll.
Unhandled exception at 0x5D9F74E3 (nvoglv32.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000.
In the old environment the application worked as expected. I didn't changed anything of the project or source code. The only difference was the language of the Visual Studio installtion which is English now and was German before. Therefore I created a new project and adopted all settings, but the error remains.
In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements() which referrs to the gemoetry pass of my deferred renderer.
After some reseach I found out that nvoglv32.dll is from Nvidia and is about a services called Compatible OpenGL ICD. Does that somehow mean that my application runs in a compatible mode? That sounds like a mode to support older applications and I want mine to run in a regular mode! By the way I installed the lastest stable drivers for my video card.
To be honest, I have no clue how to approach fixing this crash. What could cause it and how to fix it?
Update: I found a post on Geforce Forums about my issue. Although there was no reply, the autor could fix the problem by changing the order of two OpenGL calls.
Hi all,
After poking around with my application source code for a few hours, I found that calling the functions...
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
glBindVertexArray(#)
...in that order causes the crash in nvoglv64.dll.
Reversing the order of these calls to...
glBindVertexArray(#)
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
...prevents the crash and appears to be well-behaved.
Cheers,
Robert Graf
Since I do not use vertex arrays I cannot simple do this fix but there might be a similar issue. I will report my progress.
Update: I have absolutely no clue how to solve my problem. I tried different video driver versions but it makes no difference. I completely rewrote the renderer using minimal shaders and simple forward rendering. But the crash sill occurs at the first draw call.
In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements().
Most likely you had a out-of-bounds access in your code all the time, but the AMD Radeon Catalyst drivers did reserve more address space, or caught them beforehand. And now your NVidia GeForce driver's don't.
Either you're passing glDrawElements a too large number for count elements to draw, or your index buffer contains values that index beyond the range of your vertex arrays. If it's the later, then you're probably using client side vertex arrays, as VBOs usually catch out-of-bounds accesses; also those wouldn't crash your client side program, but just render garbage.
Finally I came up with a solution to fix the crash.
The SFML framework I use to create the window and more provides a function to reset the OpenGL state of the context. I called it right after window creation.
Even though I can't explain why, removing that function call solved the crash. Maybe it is because GLEW or something else isn't yet initialized that moment.
sf::RenderWindow window;
window.create(VideoMode(1024, 768), "Window Title");
window.resetGLStates(); // removing this line fixed the crash
window.setVerticalSyncEnabled(true);