how about a feature freeze people ? FIXME: bugs bugs bugs

AppCode 3.0.4 is a very poor product. Albeit all the good things to like about AppCode, is is becoming more and more like exCode.

  • long trail of unresolved issues
  • the indexing is completely f***'d up. Imagine what swift will do to that.
  • performance sucks beyond belief (even exCode is better)
  • etc ....

so, how about stopping piling up useless stuff like 'modern syntax' 'this could be improved'  etc ... and focus on the primary purpose of the product : create a working app. Let me spell that : code, assemble resources, compile and test. I understand the need for swift, but right now the prospect is scary within AppCode.

18 comments

I have more faith in the team than you I guess; but I think they're quire capable of doing both, and often times new development can justify to line-managers picking up technical debt that often leaves those hard to clear bugs stuck in the tracker for long periods of time.

I say go full force with swift..

The performance issues are bad; when it happens. I've not reproduced mine in 2 days. Better than grumbling here, you should be voting for, and adding info to all the bugs that are pain points for you.

Don't want to come across as a kiss-arse, things jetbrains do sometimes irk me too; but the team have proven their metal to me for the last 2 years, and I think supporting them with feedback and info is the best bet to achieving your goals.

0

For example, now that AppCode is fully bootstraped, they should try to create AppCode with AppCode. I dont think any of their developpers would like the experience after the code base reaches ... say 50Kslocs. Also, they should be using AppCode on an MBP to get a real feel of what real people who work (here and there) are experiencing with the product.

Two bugs come and come again, are closed or hidden in 'this is a subtask of #blablabla.  Performance and piss-poor indexing. AppCode devs should be able to recognize this with any, however dumb-ass, non-regression test suite before any release. Hell, they should see it in their unit and integration tests.

Right now, i tuned the jvm myself, alleviating some of the bad performance. But, the product is square unusable. The index carps out on me every hour of active work or so, forcing me to close and reopen the project. Worse, i have successfully corruptes the code base of another product (thank god for git).

At the end of the day, i am quite sensitive to the amount/quality of work i can dish out : AppCode is becoming like Windows and Xcode. I spend a non-trivial amount of time working ON the tool instead of working WITH the tool, ant that irks me no end. Last good build for me was 1.6EAP, where i could spend the majority of my time on my own stuff, able to deliver the goods as I expect from myself.

So, you are correct, i am losing faith in the team. I have mentionned performance quite often in the past (here and YouTrack). All my tickets are closed, yet they reappear like magic at every release. So, contrary to you, my confidence is reaching an all time low. Instead of constantly asking for the same boring information, i would challenge the team to do some real testing before dishing out a POS like 3.0.4.

0

I'm sad you feel like that. I use a mac mini with a fusion drive and performance is fine in 100k projects, I remember I didn't enjoy appcode or Unity (I do both) on my mbp, and when I have to use my mbp, I remote into my mac mini.. I guess that say's a lot; you definitely have a valid point.

However, I do get the extremely irritating indexing bug, where thigns are red inexplicably in some source files; but I don't know how to help them diagnose it as aI can't go giving them more than 100k lines of client source code to diagnose the issue :(

You should share your optimizations with other readers who are on slower machines, I'm sure they would appreciate them.

Dog fooding is not a bad idea; perhaps they should make an effort to do that. I still think that a freeze is not necessarily essential, and that they best know how to get out of this s(h)ituation.. still, performance is critical, and people shouldn't need fusion drive's to use the product.

0

Remoting into a 'muscular' box is a good idea, however I find myself at client sites where my only lifeline is a tether to my iPone's hot spot. Wire speed is an issue   I am currently juggling 3 code-bases , ranging from 275K to 425Kslocs.

re performance on an MBP : use large page files (i use 256m) and shoot-up the prem gen (384m), compressed strings and strings cache. Here is my current setup (1.6 jvm, 64bits) , still studying the various GC elements ... some in here may be fighting one another. This eliminated a bunch of beach balls, but editing is still a major pain in the neck. I can type much faster and accurately than AppCode offers suggestions for autocomplete.Except that , AppCode is so slow that i am constantly in the type-ahead buffer, reaching ";" before i even see the first character i entered.

-Xms1g
-Xmx4g
-XX:PermSize=384m
-XX:MaxPermSize=384m
-XX:+UseLargePages
-XX:LargePageSizeInBytes=256m
-XX:ReservedCodeCacheSize=96m
-XX:+UseCompressedOops
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=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


... and yes, i am dying to get into swift , my personnel patterns are very lambda'ish. Blocks work, but can make code perlish (write-only).

0

Yves, you've mentioned that you have 3 rather big projects. Do you open all 3 in AppCode at the same time or you only have one open at a time?

0

Project A is published and under 'light maintenance', mostly always closed.

Project B has B1 being refactored to B2 (new graphics package, going to ARC because graphis lib went ARC ... although now that I am done, i cant see the hype about ARC).

I am refactoring, so sometimes B1 and B2 are open. Now that i am near the end of that refactoring hell only B2 is open. Project A has been published a while, i am integrating some goodies for an update, but this project is 'standalone'.   BUT ... when A is closed and i am working on B2, AppCode sometimes finds stuff in A !!!! (global search and replace), and if i am not careful CHANGES STUFF IN THE CLOSED PROJECT.  I got bitten real bad by this bad-form hidden , yet another cache cache.

Now, if you want to ccorrupt the index real quick, just drag one protocol .h file from AppCode navigator B1 to a group in AppCode navigator B2.

ps: having one or 3 open has no impact on performance ... it sucks. Recently, just working with B2 alone, i am getting index corruptions very often (change a method signature, add a Protocol to a class, delete a line of code ! then reinsert it .... etc)

0

The problem with files, leaking into another project is no question important, we'll investigate.
I'm more interested now in how opening several projects affect the performance. Do you experience the problems you've mentioned when only one project is open?

0

Anton, the performance is so bad with one project open that i cant tell if it is worse with two. I often type blind until i enter ";" . Then eventually the editor figures out if I have misspelled references and i fix them.

Regarding the other problem, it may be related to performance and indexing (just a suggestion) ... maybe both projects are in the 'files to index' list.

0

OK, thanks Yves.
We are still waiting for snapshots from you - they'll definitely help.

0

here is one .... there is usually a very long period when i open a project (after indexing is complete and symbols a
re loaded). I just snapped cpu here during that period.



Attachment(s):
OC-137.148_yvesleborg_12.09.2014_07.45.37.zip
0

Yves, thanks for the snapshot, please try to disable "Clang isues" inspection group. Will this help?

0

failed attempt to answer, the snapshots dont fit
Screen Shot 2014-09-12 at 8.44.52 AM.png
Screen Shot 2014-09-12 at 8.43.24 AM.png

how can i send you the cpu snaps ... ning barfs here (even with just the noclang one)



Attachment(s):
Screen Shot 2014-09-12 at 8.43.24 AM.png
0

Yves, here is a bug report for this problem (UI locked after opening).
Please file the following issues derectly into the tracker - forum doesn't allow attaching snapshots.

0

Anton, i am confused. The forum did allow me to input the first snapshot.

  • Did you determine from the snapshot that it was a clang inspections loading issue, as per is a bug report  ?
  • If yes, the next two i wanted to enter are related to general sluggishness when editing code ... i could not see the difference with/without clang inspections. Do you still want them in the bug report ?
  • Do you want me to reenter the description about sluggishness ?  


PS : I put the description as a screen shot because the forum web site is broken. You cant even cancel a post after you put an attachment that is too big. Ning complains again. Nor can you remove the attachment to permit at very least to persist the text.

0

Afaik, there's something like a per-user size and time limit to uploads/posts (it's a Clearspace intricacy).
Yes, from the snapshot you've attached the pleace where the problem occurs is clear. Though it should not affect general performance, cince only performed once.
But the cause of the problem is not that clear - it may be related to you custom vm options, we haven't investigated yet.

As for the typing performance, yes, the snapshots in separate requests will be helpful.

0

First of unless you have a specific need to use 1.6 JVM I would recommend you to update your JDK/JVM to 1.7 laest update for mac.

Appcode by default uses 1.6* version of JVM, to switch right click on appcode in applications select ''Show Package Contents'--open 'Contents' folder double click on info.plist to open and edit the Info.plist locate the JVM options at the bottom of the file modfiy the JVM version that has 1.6* to 1.7* dont forget to restart appcode if its open already :)

You dont need to have these many JVM options set, modern JVM are perfectly capable and programmed to select the best options for the platform they are launched for, having said that I would use a few minimum/basic tuning options to tune your JVM

Since you are using nearly 4gig I assume your machine has atleast 8G ram? It is not just appcode running on your machine it would be much more then that, having all the memory dedicated to JVM and having constant GC would have a negative effect and will have constant CPU spikes.

provided you have 8g of ram, then you can use this

-Xms4g
-Xmx4g
-XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=256m
-XX:+UseCompressedOops

dont use different options for min and max memory allocation, this forces your JVM to constantly resize this comes at a cost its better to set them both the same

thats all you need and nothing more rest will be auto tuned by the JVM for your system.

Enjoy

Updated the post to show how to switch Appcode to use JVM 1.7

0

good man!

great settings. I have 16gb and used your settings. Appcode is now much much faster than it was (and I'm on a fusion drive, so we're now talkign super fast).

I've even found some of the class files that previously had a bug manifest not showing code completions for impmorted header files are now fixed.

T H A N K  Y O U! :D

0

Note of warning:
If you decide to use suggested VM options, make sure you remove -XX:+UseCompressedStrings (see details).
Also keep in mind that we don't support such customizations, so use them at your own risk.

0

Please sign in to leave a comment.