Open Radar

 
Summary:
Facebook is on its way to having hundreds and then thousands of Xcode project targets. Xcode's performance is already buckling under the pressure of having [REDACTED] targets. To see how this is going to go in the future, I benchmarked pathological Xcode projects like ours will be in the future. Xcode becomes very unresponsive once the number of targets hits 1000, even if the targets are trivial (a single file with a single C function).

Steps to Reproduce:
I generated four kinds of projects, attached:
1. 1 target with 1000 files in it.
2. 1001 targets, 1 file each. Autogenerated scheme and find implicit dependencies.
3. 1001 targets, 1 file each. Hand-crafted scheme with every target listed.
4. 1000 subprojects, 1 target each, 1 file each. Autogenerated scheme and find implicit dependencies.

I used one instance of Xcode for all benchmarks, opening and closing projects. I cleared DerivedData between each run. I tested loading time to interaction (TTI), closing TTI, build-from-clean time, and incremental (zero files edited) build time. Indexing was also disabled in defaults since it seemed that Xcode would _never_ become responsive in some cases with indexing enabled.

Expected Results:
Xcode should always start after a few seconds. An incremental build with zero files changed should always take under a second.

Actual Results:
Benchmarks taken on latest MBP Retina 15", 16gigs of ram.

== 1 target, 1000 files each ==
Xcode TTI: 1.77s
Clean Build: 3.91s
Incremental build: 0.2s
Close Xcode TTI: 0.75s

== 1000 targets, 1 files each, implicit scheme ==
Xcode TTI: 21.09s
Clean Build: 15.23s
Incremental build: 7.45s
Close Xcode TTI: 9.82s

== 1000 targets, 1 files each, explicit scheme ==
Xcode TTI: 97.39s
Clean Build: 18.34s
Incremental build: 9.6s
Close Xcode TTI: 17.93s

== 1000 projects, 1 targets each, 1 files each, implicit scheme ==
Xcode TTI: 48.66s
Clean Build: 26.06s
Incremental build: 8.57s
Close Xcode TTI: 35.15s

== Facebook workspace, [REDACTED] ==
[REDACTED, numbers are similar to pathological cases above]

Looking at these numbers, it is likely that in the future opening the Facebook project will take [REDACTED]. We are hesitant to add more targets since target count seems to contribute heavily to sluggishness.

Version:
OS X 10.8.4, Xcode 5 production.

Notes:
If possible, I would like to work with someone on the Xcode team to resolve these issues for Facebook's use in particular. It is important enough to Facebook's iOS productivity that working around Xcode performance issues is now my fulltime responsibility. You can contact me at [REDACTED].

Configuration:


Attachments:
'xcodestress.zip' was successfully uploaded.