Juce and XCode - Auto Completion is too slow

Hi Guys, I am using juce 7.0.5 and Xcode 14.3, the auto completion is too slow for every xcode version I had ever used with juce. Anyone facing the same issues ?

As I was followinf matkat music tutorials, his xcode auto completion seem faster in videos. What will be the solution ?

Get a faster machine? Or switch to CLion. I did and don’t regret it.

2 Likes

Hi austrianaudioJV, Thank you for reply, I am already using Macbook Pro 16 inch M1 Pro machine, so i think its fast only.
Your second idea of switching to clion, how we can use it to develop iOS applications with clion ?

First of all, take this advice with a pinch of salt - you are correct that your machine should be fast enough for XCode, although there are many factors that can effect the speed of XCode… if you are finding autocomplete unusable, that is an unusual situation and might imply that you’ve got something like a cyclic path setting, or perhaps too many redundant paths to sources in your project, or indeed that you’ve got to let your (brand new?) Macbook finish indexing its filesystem, which is another thing that can slow XCode down, as it uses Spotlight for a lot of things. So maybe take a step back and see if mdworker is still in the middle of indexing … See What are mdworker_shared, mdworker & mds|Fix High CPU Usage for details, and maybe Reddit - Dive into anything for clues on what you could also look at …

As for CLion, its use still requires that you have XCode on your system, as - after all - thats how you get access to the compiler and frameworks required to build iOS and MacOS apps - but it can fire off an xcodebuild just as easily as XCode can. Here is a pretty good article that compares the two and might answer your questions better than I would: Battle Of The IDEs: Xcode Vs CLion

1 Like

Hi there, I have also been interested in CLion. Is autocompletion faster in CLion than in XCode in your machine? And what features of CLion, which XCode lacks, do you find most useful? Thanks!

I had checked and my machine is 90% ideal most of the time, i had also tried running xcode on mac mini and other intel machines also, xcode autocompletion takes a lot of time with juce.

I am using juce from last 2-3 years with different machines too, only the xcode autocompletion is slow, other completions with visual studio, android studio and clion are faster.

I am using juce by downloading it from github releases page and gave that path to projucer, no any additional dependency, nothing. Even for simple Hello World project, autocompletion never worked fast.

Yes autocompletion in clion is way faster then xcode in my machine. But setting up clion seems to be not straight forward and also requires a paid license.

1 Like

Xcode autocompletion is extremely slow (it used to be faster back in the days) It looks like apple isn’t really committed to c++. Thats why I switched back to Visual Studio Community on a separate PC (together with Visual Assist)

2 Likes

That may be true, but has anyone compared this to auto-complete performance with Swift? I mean, does the language really matter? After all, code analysis is not done by Xcode anyway.

  1. Objective C
  2. Swift
  3. SwiftUI
  4. native C integration with swift

Autocomplete works fast for all of this as compared to JUCE in XCode.
JUCE Autocomplete works way faster in CLion for the same project as compared to XCode.

I can confirm that. I’m doing a lot of Swift stuff as well and auto complete is almost instant there.
For Juce C++ projects, it’s very slow. For project source code it’s okay sometimes (still waiting one or two seconds) but if you want to edit code from Juce modules, it’ completely unusable.
It’s a shame because everything else is working fine for me on Xcode and I don’t want to switch to Clion, Appcode, VS Code only for better code completion. :weary:
Even Android Studio has faster auto complete…

1 Like

The problem could be because of unity builds. The JUCE module source files don’t include headers so will likely have to do a lot more work.

The problem is not related to unity builds. JUCE just needs to include the needed headers in all headers, which can also be done using the existing build system.

We’ve discussed that at length here:

1 Like

Umm, you’ve just said it’s not unity builds then gave a solution to make it work (better) with unity builds?

JUCE does use unity builds, but that’s not what’s causing the auto complete problem.

The auto complete problem is caused by a lack of explicit includes, which can be added without changing the unity builds module system.

I’ve done it in all my modules, and showed an example to do that with juce_osc.

1 Like

Well yes, what I mean to say is that the JUCE source doesn’t include headers because you don’t generally do that in unity builds. That was my point.

That’s not the case in my experience. The JUCE codebase is the only one I’ve ever seen that isn’t using explicit/correct header includes.

What unity builds mean is that there’s one .cpp file that includes other .cpp files. For example in the VST3 SDK:

The headers for those .h and .cpp files are still correctly included.

1 Like

Wow, its cool !

so is this header problem is only with XCode ?
because other IDEs does not have this problem ?
is JUCE build code is IDE dependent ?

This is a problem in all IDEs, but some of them, like CLion, are better at handling it than others.

1 Like

I’ve seen it before but mostly on in-house stuff come to think of it. Not something I’d advocate myself because it’s a PITA and hostile towards IDEs. It means they have to grind away at all source files rather that incrementally from the current one.

CLion does it but it takes a lot of time/CPU to do so.

Makes you wonder what IDEs the JUCE team use themselves.