what's the process for raising peformance bugs?
I know youtrack; but what info do you guys need?
3.0.4 performs like utter arse. I have to restart it every 10 minutes now.. presubaly you guys need some diagnostics from me to work out what the issue is, like thread dumps etc.. is there a FAQ on how to raise a ticket with all that info.
cheers.
Please sign in to leave a comment.
First of all we need the CPU snapshot. Screencast of what's going on is also appreciated.
here is a FAQ: https://intellij-support.jetbrains.com/entries/29983118-Reporting-performance-problems
is there a way of re-opening bugs in YouTrack ... sometimes i get the feeling that just reopening bugs should be enough (pretty much on every release i'd say). For example, editing .pch or .h files included in a .pch freeses the GUI for long periods ... still ... or yet again ? ...
Yves, just ping us in the corresponding issue and we'll reopen it should it be still actual.
http://youtrack.jetbrains.com/issue/OC-6411
and yes, indexing takes forever, and the index breaks mid-flight very often, causing me to have to close and reopen, but the point is : subsuming that to 'slow indexing' is hiding this issue. We are talking major lag here. For the life of me, i cant see why that is closed, under any development process i could think of.
Eves, could you please take a CPU snpashot and describe the steps that cause the OC-6411 problem? Also, a snapshot for indexing as well.
i've renabled all that stuff ... as soon as i get into lags , i'll snap cpu. currently running with :
-Xms1g
-Xmx4g
-XX:PermSize=384m
-XX:MaxPermSize=384m
-XX:LargePageSizeInBytes=256m
-XX:ReservedCodeCacheSize=96m
-XX:+UseCompressedOops
-XX:ParallelGCThreads=8
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+DisableExplicitGC
-XX:+ExplicitGCInvokesConcurrent
-XX:+CMSPermGenSweepingEnabled
-XX:CMSInitiatingOccupancyFraction=60
-XX:+CMSClassUnloadingEnabled
-XX:+CMSParallelRemarkEnabled
-XX:+UseAdaptiveGCBoundary
-XX:+UseCompressedStrings
-XX:+OptimizeStringConcat
-XX:+UseStringCache
-XX:+UseFastAccessorMethods
-agentlib:yjpagent=delay=10000
-Dprofile.trace=true
not certain about (overkill ?) permgen size.
Whow! Than's an impressive list. We can't promise that these options even work, not to mention make AppCode faster. Try using the default set, only increasing Xmx/Xms.
was running with 1/4/256(permgen) ... appCode a dawwwwg.
Trying out 'tricks from the memory department' , my primary focus is to get my job done, not test appCode :)
I completely understant; still, it will be much easiet to us to investigate performance issues, when you use default settings (so that we could compare).
Anyway, please take some CPU snapshots, we'll take a look.
say what you want, i have not even come close to a GC, have not had a single occurence of corrupt index since tuning my vm. I'll ride this while it last ...
Yves, it's good to hear that you managed to set up AppCode so that it works for you.
Still, since the problem remains with default options, we need your assistance with this issue.