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.

11 comments
Comment actions Permalink

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

0
Comment actions Permalink

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 ? ...

0
Comment actions Permalink

Yves, just ping us in the corresponding issue and we'll reopen it should it be still actual.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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 :)

0
Comment actions Permalink

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.

0
Comment actions Permalink

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 ...

0
Comment actions Permalink

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.

0

Please sign in to leave a comment.