AppCode is the slowest paid software product I've ever used

已完成

So I embarked upon the journey of applying refactor > move on a member variable.

The member variable has one getter, and that getter has only one caller in another class.

AppCode worked on this refactoring project for 14 minutes.

During that entire time, CPU usage was at 150% and the entire UI was locked up.

After the 14 minutes finished, I saw that AppCode moved the member variable and its getter to another class, but it did not even refactor the caller from the other class!! 

 

Granted, the project I am working on uses a library that is somewhat large, and I've been told that this can cause AppCode to work slowly.  That really isn't an acceptable excuse though since XCode works just fine with this library, speed-wise.  That said, I don't think it's fair to charge this much money for a product that is this slow.  Even simpler things like AutoComplete are so slow (takes 8-15 seconds to activate) that I type everything out myself.  

 

I've done all the regular steps of increasing memory usage, and all the other suggestions their (genuinely friendly) customer support staff have suggested.  The project is in C++ and I'm using AppCode 2018.3.

6
Avatar
Permanently deleted user
正式评论

Hi Saro, 

As we are already communicating via the support channel, let's finish this thread and continue investigating the problem in ZenDesk. 

I quit AppCode, relaunched it, and it's now "refreshing files..." for 20 minutes.  I can't build or run.  Anyone know what this is all about?  

 

0

I am really sad to say this, but JetBrains does not seem to finally address this problem and it re-appears over the years.

0
Avatar
Permanently deleted user

This problem is a complex of regressions appearing from time to time after big changes. It cannot be fixed once. If such problems appear, we are working on them as soon as we understand the root cause of the problem. 

0

Thanks Stanislav for your reply - and sorry for my negative comment. I still love AppCode, even if it has these itches sometimes. I have indeed learnt to keep old 'good working' versions of AppCode on the Mac in case the newer ones have this performance issues. However, I hope you guys keep making it better :-)

0

Hey guys, I'm also encounter these issues. It's take almost double the time than Xcode to compile.

I'm a developer for 6 years, being developer for both android and iOS platform and I'm working in notorious American company. 

We have a huge project, but it's compiling just fine for Xcode.

lately we tried to switch to appCode, out of 50 developers, 10 of us use it for 4 straight days.

Unfortunately it's cannot replace Xcode because of the slowness it causing, all the amazing experiences I had in Android Studio are all gone. 

I guess we going to give it a shoot next year. 

Also, if this product is no good I don't understand why charging money on it. Do a beta release, give it for free and once you all fix them issues release it again. 

 

1
Avatar
Permanently deleted user

Hey guys, I'm also encounter these issues. It's take almost double the time than Xcode to compile.

Unfortunately, that's not the same issue. That's the separate issue with the Xcode build system. Let me first describe it in details, cause this issue continuously gives a wrong impression to our customers about AppCode. Xcode has its own build system. It can be invoked a) directly from the Xcode when you work in the IDE b) via the xcodebuild command-line utility shipped by Apple in the Xcode distribution. It's important to mention that both ways are recommended by Apple. First one is obviously for building apps from the IDE, the second one for CI. 

And initially, the speed of xcodebuild was the same. Next, Apple changed the Xcode build system. But the performance of the xcodebuild remains the same though years. It's much slower then Xcode build system direct invocation, especially for incremental builds. And nothing is improved here. We also cannot improve it, since it's closed source. 

In AppCode we do not introduce our own build system. We were using the xcodebuild instead. And in the past, we had a lot of complaints about its speed. Finally, we managed to invoke the Xcode build system directly in the same way as Xcode does. All the performance problems with the compilation speed were fixed until the Xcode 10.x, where our integration was broken after changes made by the Xcode team. We spent a lot of time fixing it and temporarily switched to the xcodebuild invocation again (one, two). In AppCode 2018.3.4 and the latest 2019.1 EAP we implemented the fix and now the compilation speed should be the same. 

Another important exception is that it's the same if you continuously build in AppCode without switching to the Xcode. That's because we cannot use the same DerivedData that Xcode uses, cause it's not possible to run two compilations simultaneously on the same DerivedData. It causes a lot of conflicts, so we use a separate one. 

So, @Guycohendev, about your comment: please, try the AppCode 2018.3.4 (should be possible via free trial) or AppCode 2019.1 EAP (that is free for all for a month). Also, I'm interested in getting in touch and helping your team to adopt the product better in general - even the list of issues you have will be really helpful for us to consider them in the future. My email is stanislav.dombrovsky at jetbrains.com, feel free to drop me an email directly, so we could arrange the meeting and go deep into details. 

2

I'm understand the situation, but should we looking forward for some solution from JetBrains team? I'm big AppCode fan but I ran into performance issue and have to postpone using AppCode on current project. Yes it is huge, but it is my work and I have to deal with it. There is a lot of legacy code wide room for refactoring, but I can't do anything because of slowness. So I wan't to ask, are you guys working on your own build system? Or maybe on some other radical solution?

0
Avatar
Permanently deleted user

@Andrew What specific issue do you mean? If we are talking about the compilation speed, the fix is implemented already, as I said earlier:

>In AppCode 2018.3.4 and the latest 2019.1 EAP we implemented the fix and now the compilation speed should be the same.  

0

Not only compilation speed but also very slow resolving and syntax highlighting. Every change causes re-resolving and paralyzes the work process. In Xcode I can see compilation problems almost just after typing but in AppCode I need to start compiling for such hints. I use latest EAP version

2

I'v been experiencing the same.

Sometimes when debugging, the app freezes for like a minute then I'm able to do anything (UI Freezes).

Sometimes adding a new line takes about 15 seconds, AutoComplete as well, all operations, but it works fine after a while, then starts again. I've even increased the memory of AppCode to 4gb, but didn't solve the issue.

I'm using the latest 2019.1

2

My complaints are not about long builds. AppCode works slowly at all: starting IDE, long indexing, syntax highlighting, find usages, refactoring, autocompleting, displaying parameters hints, debugging.

Sometimes it is faster to write method names completely by self, than wait for autocomplete.

Also, AppCode does not infer types properly using Swinject.

(AppCode 2019.1)

0
Avatar
Permanently deleted user

I'm sorry to close this thread, but it's not possible to track several issues and problems here. I encourage everyone to follow the approach mentioned by Florian here

0

帖子评论已关闭。