# Slow "Name binding" phase

**URL:** <https://forums.swift.org/t/slow-name-binding-phase/21594>\
**Category:** Compiler\
**Created:** [March 14, 2019, 7:55am UTC](https://forums.swift.org/t/slow-name-binding-phase/21594 "2019-03-14T07:55:50Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [March 18, 2019, 4:01pm UTC](https://forums.swift.org/t/slow-name-binding-phase/21594/6 "2019-03-18T16:01:11Z")

</div>

Good question! Swift's binary "swiftmodule" format is already a lot faster and lazier than reading from source, so the need for an even _more_ optimized format hasn't come up as much. The one thing that's using more indirection than the Clang serialized AST format is cross-module references, which are basically using a constrained form of lookup instead of some offset into the other module structure. This means they don't need to be rebuilt (in theory) if the dependency changes in some compatible way.

(On the other hand, no one has quite the volume of Swift code to compare to the amount of Objective-C that's processed when you do `#import <UIKit/UIKit.h>`, so maybe in the future we'll want to build additional "fast cross-module references".)

The parseable interfaces that serve as the [stable module format](https://forums.swift.org/t/plan-for-module-stability/14551) _do_ have a speed problem, and so we _do_ compile those to a binary format (the existing one) and stash them in the same module cache location that Clang uses.

---

_[View the full topic](https://forums.swift.org/t/slow-name-binding-phase/21594)._
