[Swift] Method Dispatch (3): Dynamic Dispatch를 줄여보자

Increasing Performance by Reducing Dynamic Dispatch - Swift Blog

Dynamic Dispatch

Dynamic Dispatch의 사용이 무조건 나쁜 것은 아닙니다. Dynamic Dispatch 덕분에 우리는 오버라이딩도 할 수 있고, 다형성도 만들수 있고 상속도 효과적으로 사용할 수 있으니까요. 하지만 반드시 클래스를 사용해야하는 상황에서 더 이상 상속할 자식 클래스가 없다면 어떨까요? 

 

Dynamic Dispatch는 실제 구현코드를 찾아가기 위해 테이블을 탐색해야하는 오버헤드가 발생합니다. 만약 클래스에서 실행할 메서드가 명확하다면 굳이 Dynamic Dispatch를 하지 않아도 되겠죠. 

 

애플 공식 블로그에서 알려주는 세 가지 방법을 한번 알아봅시다!

class ParticleModel {
	var point = ( 0.0, 0.0 )
	var velocity = 100.0

	func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

var p = ParticleModel()
for i in stride(from: 0.0, through: 360, by: 1.0) {
	p.update((i * sin(i), i), newV:i*1000)
}

이 코드를 기준으로 Dynamic Dispatch를 줄여볼거예요!

 

방법1: 오버라이딩이 필요없다면 final을 사용하세요!

final 키워드를 클래스, 메서드, 프로퍼티에 사용하면 대상이 더 이상 오버라이딩될 수 없도록 제한합니다. 이렇게 제한된 대상들은 컴파일러가 쉽게 어떤 메서드나 프로퍼티를 선택해야할지 결정할 수 있기 때문에 Static Dispatch로 사용할 수 있게해줍니다.

class ParticleModel {
	final var point = ( x: 0.0, y: 0.0 )
	final var velocity = 100.0

	final func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

이제 point, velocity 프로퍼티와 updatePoint 메서드는 final로 오버라이딩이 제한되었기 때문에 Static Dispatch로 동작합니다. 반면에 update 메서드는 그대로 Dynamic Dispatch 이겠죠? 하위 클래스에서 재정의하게되면 어떤 메서드를 실행해야할지 불분명해지니까요.

 

클래스 전체에 final 키워드를 붙여줄 수도 있어요.

final class ParticleModel {
	var point = ( x: 0.0, y: 0.0 )
	var velocity = 100.0
	// ...
}

이렇게 하면 이 클래스는 이제 상속이 아예 불가능해집니다. 따라서 클래스 내부의 모든 메서드와 프로퍼티들이 final을 가진것과 동일하기 때문에 이 클래스에 대해 발생하는 모든 호출은 Static Dispatch로 동작합니다.

 

방법 2: private을 사용하세요!

private을 사용하면 클래스의 선언부 외부에서는 해당 메서드나 프로퍼티를 볼 수조차 없습니다. 이런 메서드나 프로퍼티들은 컴파일러가 쉽게 Static Dispatch를 결정하도록 해줍니다. 

class ParticleModel {
	private var point = ( x: 0.0, y: 0.0 )
	private var velocity = 100.0

	private func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

이렇게 원하는 프로퍼티나 메서드에 private을 붙이거나,

private class ParticleModel {
	var point = ( x: 0.0, y: 0.0 )
	var velocity = 100.0
	// ...
}

클래스 전체에 private을 지정할 수도 있어요. 이런 선언은 클래스 내부의 모든 프로퍼티에 private 접근 제어를 부여합니다.

 

방법 3: Whole Module Optimization을 사용하면 final을 추론할 수 있습니다.

Whole Module Optimization은 모듈 전체를 한번에 컴파일하게 됩니다. 따라서 기본 접근제어자인 internal로 선언된 프로퍼티나 메서드라도 전체 모듈에서 오버라이딩이 발생하는지 쉽게 파악할 수 있게 됩니다. 컴파일러는 오버라이딩이 발생하지 않는 internal 프로퍼티나 메서드에 대해서 final로 추론하기 때문에 Static Dispatch로 동작하게할 수 있습니다.

public class ParticleModel {
	var point = ( x: 0.0, y: 0.0 )
	var velocity = 100.0

	func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	public func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

var p = ParticleModel()
for i in stride(from: 0.0, through: times, by: 1.0) {
	p.update((i * sin(i), i), newV:i*1000)
}

이 코드에서 internal로 선언된 point, velocity, updatePoint는 이제 모든 파일이 한번에 컴파일되면서 이 메서드와 프로퍼티를 오버라이딩하는 영역이 모듈 내에 없음을 알고 final로 추론됩니다. 따라서 Static Dispatch로 동작합니다.

 

하지만 update 같은 경우는 public 으로 선언되었기 때문에 외부 모듈에도 접근이 가능해 final로 추론할 수 없습니다. 

(라고 해석이 되는데 public은 외부 모듈에서 서브클래싱을 허용안하지 않나요..? 3번째 방법에 대해 명확하게 아신다면 알려주세요ㅠㅜ)

 

마지막 방법이 좀 찝찝하네요.. open 이라면 명백하게 Dynamic Dispatch일텐데..

 

https://stackoverflow.com/questions/56341501/why-cant-whole-module-optimalization-infer-final-on-public-non-overridden-modul

Why can't Whole Module Optimalization infer final on public non-overridden module classes/methods in the same module?

찾았습니다..ㅋㅋㅋ 

 

저 글이 나온게 Swift2에서 나와서 public 이 open 처럼 사용될 때였다고 하네요..! open이 아닐 때만 final로 추론된다고 생각하면될 것 같습니다! open은 Swift3에서 소개되었다고 합니다.