100% cpu on startup ...
Just thought i'd refresh this one up. Now that you have a 'sustainable' business model (e.g. it costs every customer more for your product(s) ... do you think we could get rid of this nagging problem ???? AppCode version 3.3.2, osx 10.11.12, a comfortable xCode with known bugs.
Please dont gimme the old why dont you install the new version! line. Been reporting this since 2.x.
请先登录再写评论。
Hi Yves.
Sorry for the inconvenience! Could you please specify which language you are using in your project (Swift, Objective-C or mixed)? Also please capture a CPU snapshot according to this guide and send it to appcode-support at jetbrains.com. It would help us in our investigation!
You have asked me (and others) for a cpu snapshot every time. I am pretty certain from past conversations and some youtrack stale tickets that you already know the cause. I may provide you one, when the 'practical joke department' decides to start again this behaviour. You should know that the ritual to get rid of it is pretty random and usually involves one (or more) re-indexing of the project with a restart. Speaking of which, the panel with (just restart, invalidate, cancel, invalidate and restart) is completely useless. If you feel you must have a msft 'are you sure' menu, keep it simpler, with the default button on YES. As it looks, it looks like a Jetbrains debugging aid.
obj-c
Hi Yves,
I just want to describe, why we are asking about CPU snapshot for every issue with CPU, especially when we receive a report about high CPU while opening the project in AppCode. First, at startup AppCode loads caches for your project. Size of such caches can be really big, because these caches contain all information we need to perform any smart IDE feature (refactorings, navigation and so on). And currently there is no other way to perform such smart features fast except using such caches. To load these caches, IDE uses all processor cores that are available - because in other case you will not be able to use any smart feature and everybody wants these features to work as fast as it possible. So, while loading the caches CPU usage is usually high - just because we use all processor cores every time, in other case caches will load slower and it will raise much more concerns from our users rather than using all cores for a limited period of time. After IDE finishes loading caches (no progress at the bottom saying "Updating symbols..." etc) - CPU usage should be not that high. And if you experience high CPU usage after caches are loaded - it can be possible regression which we are usually trying to solve before any other issues.
Next, if you experience such issue, the only way for us to understand what happens and solve your issue quickly is to receive CPU snapshot, just because it will show us, which thread consumes too much CPU, is it regression or any other issue. Using it we will identify an exact place where such problem happens in our code and fix it. If we cannot receive CPU snapshot - it will take much more time for us to understand all possible causes for such issue.
We understand, that such explanation may be not enough for you. And we are continuously trying to improve the speed of caches loading, but for the moment we cannot find the way to optimize it significantly.
So, the first question from my side is if you experience high usage of CPU after caches were loaded at startup?
Stanislav, in this instance, the screenshot was taken minutes after the cache load-up was finished. It seems there is a 'clingy' process in one of the cores. As i said (and i can understand how difficult it can be to chase a zombie) ... this is not systematic and can take quite a bit of time before it happens again. Since 'invalidate and restart' is my favorite sport these days ( the index gets mangled very often ), i restart AppCode up to 10 times a day. Even so, the next occurence could be long to come by. I will try to do some 'monkey testing' moving forward to see if i can force the issue (and if yes, i'll provide you the snapshot).
fwiw : i think i caused this by pressing the 'debug' button prematurely, ie the list of targets became available before completion of the startup cache scaffolding.
Today I had the dreaded 100% cpu after my n'th restart (actually, this was a 'puter' reboot because Xcode had lost one of my devices , did not see it anymore) and only a reboot cures that.
So, i had done what Anna recommended (revert to the underpowered appcode.vmoptions, with the yjp agent line) but ... no matter how i try i never get the 'cpu snapshot' menu. This is my current ~/Library/Preferences/AppCode33/idea.vmoptions file content :
-Xss2m
-Xms256m
-Xmx1200m
-XX:NewSize=128m
-XX:MaxNewSize=128m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=96m
-XX:+UseCompressedOops
-agentlib:yjpagent=delay=10000
and this is what i get with these options
notice the absence of a 'cpu snapshot' on menu, and the presence of TWO for the price of one memory snapshot icons. How do i right this so i can give you a snapshot next time around ?
Yves,
I'm sorry for replying so late. The problem I think is in the filename. For AppCode you should set VM values in appcode.vmoptions file. So, the full path should be
~/Library/Preferences/AppCode33/appcode.vmoptions.
Please, let me know if it helps in your case.
Hello Sanislav, yes ! that did it for me. Incredibly, when starting with the vmoptions, I had the 100%+ cpu condition going and took a snapshot.
DarkMax:Snapshots yvesleborg$ ftp ftp://ftp.intellij.net/.uploads/
Connected to ftp.intellij.net.
220 FTP Server ready.
331 Anonymous login ok, send your complete email address as your password
230 Anonymous login ok, restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Type set to I
250 CWD command successful
ftp> put appcode-2014-11-05-shutdown.snapshot
local: appcode-2014-11-05-shutdown.snapshot remote: appcode-2014-11-05-shutdown.snapshot
229 Entering Extended Passive Mode (|||27527|)
150 Opening BINARY mode data connection for appcode-2014-11-05-shutdown.snapshot
226 Transfer complete
103980540 bytes sent in 03:33 (474.92 KiB/s)
ftp> quit
221 Goodbye.
Hi Yves.
Sorry for the delay. I've created the issue: https://youtrack.jetbrains.com/issue/OC-13380. Please subscribe.