12 · CPU와 성능

import Foundation

func classify(_ label: String, _ work: () -> Void) {
    let wallStart = ContinuousClock.now
    let cpuStart  = clock()                       // 프로세서가 실제로 돈 시간(근사)
    work()
    let wall = wallStart.duration(to: .now)
    let cpu  = Double(clock() - cpuStart) / Double(CLOCKS_PER_SEC)
    print("\(label): wall=\(wall), cpu≈\(cpu)s")
    // cpu ≈ wall  →  CPU-bound (계산이 병목)
    // cpu << wall →  I/O-bound (대부분 대기)
}

import Foundation

// CPU-bound는 코어 수에서 이득이 포화된다. 그 이상은 컨텍스트 스위칭 낭비다.

let coreCount = ProcessInfo.processInfo.activeProcessorCount

// ✅ ① concurrentPerform — 런타임이 코어에 맞춰 분배한다
func renderTiles(_ tiles: [Tile], into output: UnsafeMutableBufferPointer<Pixel>) {
    DispatchQueue.concurrentPerform(iterations: tiles.count) { i in
        output[i] = render(tiles[i])
    }
}

// ✅ ② TaskGroup을 쓸 때는 '청크 개수'를 코어에 맞춘다
func processImages(_ images: [RawImage]) async -> [Processed] {
    let chunkSize = max(1, (images.count + coreCount - 1) / coreCount)

    var chunks: [ArraySlice<RawImage>] = []
    var i = images.startIndex
    while i < images.endIndex {
        let j = images.index(i, offsetBy: chunkSize, limitedBy: images.endIndex)
                ?? images.endIndex
        chunks.append(images[i..<j]); i = j
    }

    return await withTaskGroup(of: [Processed].self) { group in
        for chunk in chunks {
            group.addTask { chunk.map(process) }      // Task 하나 = 청크 하나
        }
        var out: [Processed] = []
        for await part in group { out += part }
        return out
    }
}

// ✅ ③ QoS로 코어 종류까지 유도한다
func background() {
    DispatchQueue.global(qos: .utility).async { }     // E 코어로 갈 수 있다
    DispatchQueue.global(qos: .userInitiated).async { } // P 코어 우선
}

// ❌ 작업마다 Task 하나 — CPU 작업이면 스위칭만 늘어난다
// for image in images { Task { _ = process(image) } }

struct Tile {}; struct Pixel {}; struct RawImage {}; struct Processed {}
func render(_ t: Tile) -> Pixel { Pixel() }
func process(_ r: RawImage) -> Processed { Processed() }

import Foundation

// I/O는 CPU가 노는 시간이 대부분이다. 스레드를 늘려도 대기 시간은 그대로다.
// 필요한 건 '대기를 겹치는 것'이고, 그건 async로 충분하다.

// ❌ 동기 API로 스레드를 붙잡는다
func downloadAllBad(_ urls: [URL]) {
    for url in urls {
        DispatchQueue.global().async {
            _ = try? Data(contentsOf: url)      // 스레드 하나가 대기로 죽는다
        }
    }
}

// ✅ async로 왕복을 겹친다 — 스레드는 몇 개 안 쓴다
func downloadAll(_ urls: [URL]) async throws -> [Data] {
    try await withThrowingTaskGroup(of: (Int, Data).self) { group in
        for (i, url) in urls.enumerated() {
            group.addTask { (i, try await URLSession.shared.data(from: url).0) }
        }
        var out = [Data?](repeating: nil, count: urls.count)
        for try await (i, d) in group { out[i] = d }
        return out.compactMap { $0 }
    }
}

// ✅ 동시 실행 수는 제한한다 — 무제한은 서버·메모리에 부담이다
func downloadLimited(_ urls: [URL], limit: Int = 6) async throws -> [Data] {
    var results: [Data] = []
    var iterator = urls.makeIterator()

    try await withThrowingTaskGroup(of: Data.self) { group in
        // 처음 limit개만 시작
        for _ in 0..<limit {
            guard let url = iterator.next() else { break }
            group.addTask { try await URLSession.shared.data(from: url).0 }
        }
        // 하나 끝날 때마다 하나 추가 — 항상 limit개가 진행 중
        while let data = try await group.next() {
            results.append(data)
            if let url = iterator.next() {
                group.addTask { try await URLSession.shared.data(from: url).0 }
            }
        }
    }
    return results
}

import Foundation

// ❌ ① 동기 블로킹을 전역 큐에 대량 투입 → thread explosion
func explosion(_ urls: [URL]) {
    for url in urls {
        DispatchQueue.global().async { _ = try? Data(contentsOf: url) }
    }
    // 워커 스레드가 한계까지 늘어나고, 그 뒤 작업은 굶는다
}

// 스레드 수를 실제로 관찰해 보면 바로 보인다
func threadCount() -> Int {
    var count: mach_msg_type_number_t = 0
    var list: thread_act_array_t?
    guard task_threads(mach_task_self_, &list, &count) == KERN_SUCCESS else { return 0 }
    if let list {
        vm_deallocate(mach_task_self_, vm_address_t(UInt(bitPattern: list)),
                      vm_size_t(Int(count) * MemoryLayout<thread_t>.size))
    }
    return Int(count)
}

// ❌ ② 협력 풀에서 블로킹 — 워커가 코어 수만큼뿐이라 더 치명적이다
func starvation() async {
    await withTaskGroup(of: Void.self) { group in
        for _ in 0..<100 {
            group.addTask {
                Thread.sleep(forTimeInterval: 1)    // 💥 워커를 통째로 막는다
            }
        }
    }
}

// ❌ ③ 메인 스레드에서의 무거운 연산
@MainActor
func heavyOnMain(_ data: [Double]) -> Double {
    data.reduce(0) { $0 + sqrt($1) }    // 100만 개면 프레임을 놓친다
}

// ✅ 각각의 올바른 형태
func fixed(_ urls: [URL]) async throws {
    // ① async I/O
    _ = try await withThrowingTaskGroup(of: Data.self) { group -> [Data] in
        for url in urls { group.addTask { try await URLSession.shared.data(from: url).0 } }
        var out: [Data] = []; for try await d in group { out.append(d) }; return out
    }

    // ② 지연은 Task.sleep
    try await Task.sleep(for: .seconds(1))

    // ③ 무거운 연산은 메인 밖
    _ = await Task.detached(priority: .userInitiated) {   // ⚠️ detached도 같은 협력 풀에서 돈다 —
        // 액터 컨텍스트만 끊을 뿐이라, 길게 도는 계산은 중간에 await Task.yield()로 양보하거나
        // concurrentPerform으로 넘겨야 풀을 잠식하지 않는다
        (0..<1_000_000).reduce(0.0) { $0 + Double($1).squareRoot() }
    }.value
}

let n = 4_000
var a = [Int](repeating: 1, count: n * n)   // 하나의 연속 버퍼

// 행 우선: 이웃 원소를 차례로 → 캐시라인 재사용 (빠름)
var s = 0
for i in 0..<n { for j in 0..<n { s &+= a[i*n + j] } }

// 열 우선: 매번 n칸씩 건너뜀 → 접근마다 새 캐시라인 (느림)
for j in 0..<n { for i in 0..<n { s &+= a[i*n + j] } }

import Foundation

// 포인터를 따라가는 구조는 매 접근이 새 캐시라인을 건드린다.
// 연속 메모리 + 순차 접근이 프리페처가 가장 잘 예측하는 형태다.

// ❌ 링크드 리스트 — 노드가 힙 여기저기에 흩어져 있다
final class Node {
    var value: Double = 0
    var next: Node?
}
func sumList(_ head: Node?) -> Double {
    var total = 0.0, node = head
    while let n = node { total += n.value; node = n.next }   // 매번 캐시 미스
    return total
}

// ✅ 연속 배열 — 한 캐시라인에 Double 여러 개가 함께 온다
//    (hw.cachelinesize 기준 Apple Silicon 128B → 16개, x86 64B → 8개)
func sumArray(_ values: ContiguousArray<Double>) -> Double {
    var total = 0.0
    for v in values { total += v }
    return total
}

// ✅ 경계 검사까지 빼고 싶으면
func sumFast(_ values: ContiguousArray<Double>) -> Double {
    values.withUnsafeBufferPointer { buf in
        var total = 0.0
        for i in buf.indices { total += buf[i] }
        return total
    }
}

// 차이를 직접 재 본다 — 보통 자릿수가 다르다
func benchmark(n: Int = 1_000_000) {
    var array = ContiguousArray<Double>(repeating: 1, count: n)
    var head: Node? = nil
    for _ in 0..<n { let node = Node(); node.next = head; head = node }

    let clock = ContinuousClock()
    print("배열   \(clock.measure { _ = sumArray(array) })")
    print("리스트 \(clock.measure { _ = sumList(head) })")
    _ = array
}

// ⚠️ 클래스 배열([Node])도 마찬가지다 — 배열은 연속이지만
//    각 요소는 힙 포인터라 실제 데이터는 흩어져 있다.

import Foundation

// 일부 필드만 훑는데 AoS로 두면, 쓰지 않는 필드까지 캐시라인에 딸려 온다.

// AoS(Array of Structs) — 한 개체를 통째로 다룰 때 유리
struct ParticleAoS {
    var x, y: Float          // 위치
    var vx, vy: Float        // 속도
    var color: UInt32        // 색
    var lifetime: Float      // 수명
}
// 24바이트 × 100만 = 24MB. 위치만 읽어도 전부 캐시에 올라온다.

// SoA(Struct of Arrays) — 일부 필드만 훑을 때 유리
struct ParticlesSoA {
    var x = ContiguousArray<Float>()
    var y = ContiguousArray<Float>()
    var vx = ContiguousArray<Float>()
    var vy = ContiguousArray<Float>()
    var color = ContiguousArray<UInt32>()
    var lifetime = ContiguousArray<Float>()
}

// ✅ 위치만 그린다 — vx·vy·color·lifetime은 아예 읽지 않는다
func draw(_ p: ParticlesSoA) {
    for i in p.x.indices { plot(p.x[i], p.y[i]) }    // 워킹셋 8MB
}

// ✅ 물리 갱신 — 위치와 속도만
func integrate(_ p: inout ParticlesSoA, dt: Float) {
    p.x.withUnsafeMutableBufferPointer { xs in
        p.vx.withUnsafeBufferPointer { vxs in
            for i in xs.indices { xs[i] += vxs[i] * dt }
        }
    }
}

// ⚠️ SoA는 코드가 장황해지고, 한 개체를 통째로 다루는 연산은 오히려 느려진다.
//    "이 루프가 실제 병목이다"가 확인된 뒤에만 바꾼다.

func plot(_ x: Float, _ y: Float) {}

import Foundation

// 캐시 최적화는 코드를 읽기 어렵게 만든다. 그 대가를 치를 가치가 있는 곳은
// 프로파일러가 지목한 소수의 함수뿐이다.

// ✅ 순서 ① 먼저 측정한다 — 추측으로 시작하지 않는다
//    Instruments → Time Profiler → 실제 사용 시나리오 녹화
//    "가장 큰 덩어리"부터 본다. 절대 밀리초가 아니라 상대 비중이 기준이다.

// ✅ 순서 ② 알고리즘·자료구조를 먼저 본다 (효과가 훨씬 크다)
//    O(n²) → O(n log n)이 캐시 최적화보다 백 배 낫다

// ✅ 순서 ③ 그다음에야 지역성
func optimizedHotLoop(_ values: inout ContiguousArray<Float>) {
    values.withUnsafeMutableBufferPointer { buf in
        for i in buf.indices { buf[i] *= 0.5 }
    }
}

// ❌ 차가운 경로까지 이렇게 비트는 것 — 읽기만 어려워지고 이득이 없다
func coldPath(_ settings: [String: String]) -> String {
    settings["theme"] ?? "light"        // 앱 시작에 한 번 도는 코드
    // 여기에 SoA·unsafe 포인터를 쓸 이유가 전혀 없다
}

// ✅ 최적화한 코드에는 '왜'를 남긴다
/// ⚡️ 핫스팟: 프레임마다 100만 회 호출된다 (Time Profiler 기준 전체의 34%).
/// 경계 검사 제거로 약 2.1배 개선. 일반 for-in으로 되돌리지 말 것.
/// 측정: 2026-07-27, iPhone 15 Pro, Release
func criticalPath(_ buf: UnsafeMutableBufferPointer<Float>) {
    for i in buf.indices { buf[i] *= 0.5 }
}

// ✅ 개선 효과를 회귀 테스트로 고정한다
func test_핫루프_성능() {
    var values = ContiguousArray<Float>(repeating: 1, count: 1_000_000)
    let elapsed = ContinuousClock().measure { optimizedHotLoop(&values) }
    // ⚠️ assert는 -O에서 조건 평가 자체가 사라진다 — Release로 돌리는 성능 회귀 검사는
    //    XCTAssert(또는 precondition)로 써야 한다.
    XCTAssertLessThan(elapsed, .milliseconds(10), "핫루프 성능 회귀: \(elapsed)")
}

var queue = Array(0..<100_000)
while !queue.isEmpty {
    let x = queue.removeFirst()   // 앞을 지우면 뒤 전부를 앞으로 당김 → 매번 O(n)
    _ = x                          // 루프 n번 × O(n) = 전체 O(n²)
}

// 개선: 인덱스로 순회하거나 swift-collections의 Deque(앞 제거 O(1)) 사용

func bench(_ n: Int, _ body: () -> Void) -> Duration {
    let start = ContinuousClock.now
    body()
    return start.duration(to: .now)
}
for n in [8, 64, 512, 4096] {
    print(n, bench(n) { /* 후보 알고리즘 */ })
}   // 작은 n과 큰 n에서 승자가 뒤바뀌는지 관찰

import Foundation

// 점근 복잡도는 n이 클 때의 이야기다. 내 n이 20이면 그 논의는 무의미하다.

enum Scale {
    case screen         // 20~100      화면에 보이는 행
    case page           // 100~1,000   한 페이지
    case session        // 1만~10만    누적 스크롤
    case archive        // 100만+      전체 동기화
}

// ✅ n에 따라 구현을 다르게 고른다
struct Lookup {
    private let items: [Item]
    private let index: [String: Item]?

    init(_ items: [Item]) {
        self.items = items
        // 작은 n에서는 인덱스 구축 비용이 조회 이득보다 크다
        self.index = items.count >= 64
            ? Dictionary(items.map { ($0.id, $0) }, uniquingKeysWith: { a, _ in a })
            : nil
    }

    func find(_ id: String) -> Item? {
        if let index { return index[id] }
        return items.first { $0.id == id }     // 선형 스캔이 더 빠른 구간
    }
}

// ✅ 상한을 문서로 못 박아 두면 최적화 범위가 명확해진다
/// 이 목록의 상한: 서버가 페이지당 100개, 최대 50페이지 → n ≤ 5,000
/// 이 범위에서는 O(n) 선형 처리로 충분하며, 인덱스는 불필요하다.
struct FeedList { var items: [Item] = [] }

// ✅ 실제 분포를 로그로 수집해 가정을 검증한다
func recordSize(_ n: Int) {
    // Analytics.record("list_size", value: n)
    // p50/p95/p99를 보고 "우리 n"을 숫자로 확정한다
}

struct Item { let id: String }

import Foundation

// "언젠가 100만 개가 될 수도 있으니까"로 시작한 최적화는
// 대부분 도달하지 않는 미래를 위해 지금의 가독성을 태운다.

// ❌ 20개짜리 설정 목록에 B-tree 인덱스를 직접 구현
final class OverEngineeredSettings {
    private var btree: BTreeNode?          // 💥 설정 20개에 트리
    func value(for key: String) -> String? { nil }
}

// ✅ 그냥 딕셔너리 — 읽기 쉽고 충분히 빠르다
struct Settings {
    private var storage: [String: String] = [:]
    func value(for key: String) -> String? { storage[key] }
}

// ✅ 판단 기준: "지금 n에서 측정했을 때 문제인가?"
func shouldOptimize(currentN: Int, measuredMs: Double, budgetMs: Double) -> Bool {
    measuredMs > budgetMs        // 측정값이 예산을 넘을 때만
}

// ✅ 미래 대비는 '최적화'가 아니라 '경계'로 한다
//    지금은 단순하게 두되, 나중에 바꿀 수 있게 인터페이스를 분리해 둔다
protocol ItemLookup {
    func find(_ id: String) -> Item?
}

struct LinearLookup: ItemLookup {          // 지금
    let items: [Item]
    func find(_ id: String) -> Item? { items.first { $0.id == id } }
}

struct IndexedLookup: ItemLookup {         // n이 커지면 이걸로 교체
    let index: [String: Item]
    func find(_ id: String) -> Item? { index[id] }
}
// 교체 지점이 한 곳이므로, 필요해질 때 바꾸면 된다

final class BTreeNode {}
struct Item { let id: String }

import Foundation

// 겉보기엔 O(n) 루프인데 안에 O(n) 연산이 숨어 O(n²)가 되는 패턴들.

// ❌ ① 문자열 이어붙이기
func joinBad(_ parts: [String]) -> String {
    var out = ""
    for p in parts { out += p }            // Swift String은 지수적으로 늘어 분할상환 O(n)이다
                                           // (O(n²)가 아니다 — joined()와의 차이는 상수 인자)
    return out
}
func joinGood(_ parts: [String]) -> String {
    parts.joined()                          // 전체 크기를 먼저 계산해 한 번 할당
}

// ❌ ② removeFirst
func drainBad(_ queue: inout [Job]) {
    while !queue.isEmpty { run(queue.removeFirst()) }    // 매번 전체 이동
}
func drainGood(_ queue: [Job]) {
    for job in queue { run(job) }
}

// ❌ ③ contains로 중복 검사
func dedupBad(_ items: [Item]) -> [Item] {
    var out: [Item] = []
    for i in items where !out.contains(where: { $0.id == i.id }) { out.append(i) }
    return out
}
func dedupGood(_ items: [Item]) -> [Item] {
    var seen = Set<String>(minimumCapacity: items.count)
    return items.filter { seen.insert($0.id).inserted }
}

// ❌ ④ COW 복사 — 루프 안에서 공유 상태인 배열을 변경
func cowTrap(_ source: [Double]) -> [Double] {
    var working = source                    // 공유 시작
    for i in working.indices { working[i] *= 2 }   // 첫 쓰기에서 O(n) 복사가 '한 번' 튄다
                                                   // (반복되지 않으므로 O(n²)는 아니다)
    return working
}
func cowAvoided(_ source: inout [Double]) {
    for i in source.indices { source[i] *= 2 }     // 유일 소유 → 복사 없음
}

// ✅ ⑤ 크기를 알면 예약
func build(_ n: Int) -> [Int] {
    var out: [Int] = []
    out.reserveCapacity(n)
    for i in 0..<n { out.append(i) }
    return out
}

struct Job {}; struct Item { let id: String }
func run(_ j: Job) {}

// Debug(-Onone): 이 제네릭은 특수화되지 않고 witness table로 동적 디스패치
func total<T: Numeric>(_ xs: [T]) -> T { xs.reduce(.zero, +) }
// Release(-O + WMO): Int 등 구체 타입으로 특수화 + 인라인 + ARC 제거 → 수십 배↑

assert(index >= 0)        // Release(-O)에서는 사라짐 → 런타임 비용 0
precondition(index >= 0)  // Release에서도 유지됨 (-Ounchecked에서만 제거)

import Foundation

// Debug(-Onone)에서는 ARC 중복·제네릭 비특수화·인라인 없음이 겹쳐
// 실제와 수십 배까지 차이 난다. Debug 숫자로 판단하면 엉뚱한 곳을 고치게 된다.

// ✅ 커맨드라인
//    xcodebuild -scheme MyApp -configuration Release build
//    swift run -c release
//    swift test -c release

// ✅ Instruments도 Release 구성으로 (Scheme → Profile → Build Configuration)

// ✅ 코드로 최적화 여부를 확인해 실수를 막는다
func assertOptimizedBuild() {
    #if DEBUG
    assertionFailure("Debug 빌드에서 벤치마크를 돌리고 있습니다")
    #endif
}

// ✅ 벤치마크 함수는 최적화로 사라지지 않게 결과를 소비한다
@inline(never)
func blackHole<T>(_ value: T) {
    withExtendedLifetime(value) {}
}

func benchmark(_ label: String, iterations: Int = 1000, _ body: () -> Void) {
    assertOptimizedBuild()

    // 워밍업 — 첫 실행의 캐시·분기예측 콜드 비용을 제외한다
    for _ in 0..<10 { body() }

    let clock = ContinuousClock()
    let elapsed = clock.measure {
        for _ in 0..<iterations { body() }
    }
    print("\(label): \(elapsed / iterations) per iteration")
}

// ⚠️ 최적화가 코드를 통째로 지울 수 있다
func wrongBenchmark() {
    benchmark("sqrt") {
        _ = (0..<1000).map { Double($0).squareRoot() }   // 결과를 안 쓰면 삭제될 수 있다
    }
}
func rightBenchmark() {
    benchmark("sqrt") {
        let result = (0..<1000).map { Double($0).squareRoot() }
        blackHole(result)                                 // ✅ 소비한다
    }
}

// ✅ XCTest의 measure도 Release 구성에서 돌려야 의미가 있다

import Foundation

// assert      : 개발 중에만 필요한 검사. Release(-O)에서 제거된다.
// precondition: Release에서도 반드시 지켜야 할 계약. 남는다.
// fatalError  : 도달하면 안 되는 지점. 항상 남는다.

struct RingBuffer<T> {
    private var storage: [T?]
    private var head = 0

    init(capacity: Int) {
        // ✅ 호출자 계약 위반 — Release에서도 잡아야 한다
        precondition(capacity > 0, "capacity는 양수여야 합니다")
        storage = Array(repeating: nil, count: capacity)
    }

    mutating func append(_ value: T) {
        // ✅ 내부 불변식 — 개발 중에만 확인하면 충분하다
        assert(head < storage.count, "내부 인덱스 오류")
        storage[head] = value
        head = (head + 1) % storage.count
    }

    func element(at index: Int) -> T? {
        // ✅ 외부 입력이면 precondition (또는 Optional 반환)
        precondition(index >= 0 && index < storage.count, "인덱스 범위 초과")
        return storage[index]
    }
}

// ⚠️ assert의 인자는 @autoclosure — Release에서 아예 실행되지 않는다
var cursor = 0
func advanceAndCheck() -> Bool { cursor += 1; return cursor < 10 }

// ❌ Debug와 Release의 동작이 갈린다
func bad() {
    assert(advanceAndCheck())      // Release에서는 cursor가 증가하지 않는다
}

// ✅ 부수효과는 밖으로 꺼낸다
func good() {
    let ok = advanceAndCheck()
    assert(ok)
}

// ✅ 도달 불가 지점
func handle(_ state: State) -> String {
    switch state {
    case .idle: return "대기"
    case .running: return "실행"
    }
}
enum State { case idle, running }

import Foundation

// -Ounchecked는 배열 경계 검사와 정수 오버플로 검사까지 제거한다.
// 그 검사가 잡아 주던 버그가 이제는 메모리 손상으로 나타난다.

// -O 에서는 이렇게 동작한다
func withChecks() {
    let array = [1, 2, 3]
    let index = 5
    // _ = array[index]        // 💥 크래시 (Fatal error: Index out of range)
    //                          //    → 명확한 오류로 즉시 멈춘다

    var value = Int.max
    // value += 1              // 💥 크래시 (Swift runtime failure: arithmetic overflow)
    _ = (array, index, value)
}

// -Ounchecked 에서는
//   array[5]  → 정의되지 않은 메모리를 읽는다. 크래시할 수도, 쓰레기 값을 줄 수도 있다.
//   Int.max+1 → 조용히 음수로 감긴다. 계산 결과가 틀리는데 아무도 모른다.

// ✅ 켜야 한다면 그 범위를 최소화하고, 안전을 코드로 증명한다
func safeSum(_ values: [Int]) -> Int {
    // 오버플로가 불가능함을 타입으로 보장한다
    values.reduce(0) { partial, v in
        let (sum, overflow) = partial.addingReportingOverflow(v)
        return overflow ? Int.max : sum      // 명시적으로 처리
    }
}

// ✅ 경계 검사를 빼고 싶으면 -Ounchecked가 아니라 이걸 쓴다
func fastLoop(_ values: [Double]) -> Double {
    values.withUnsafeBufferPointer { buf in
        var total = 0.0
        for i in buf.indices { total += buf[i] }   // 이미 경계 검사가 없다
        return total
    }
}
// 범위를 함수 하나로 좁힐 수 있고, 나머지 코드의 안전성은 유지된다

// ⚠️ 판단: -Ounchecked로 얻는 이득을 '측정'했는가?
//    대부분의 앱에서 차이는 미미하고, 잃는 것(진단 가능성)은 크다.

// 백그라운드 대량 작업은 낮은 QoS → 스케줄러가 효율(E) 코어에 배치 → 전력↓
Task(priority: .utility) { await reindexPhotos() }

// 열 상태에 따라 작업량을 조절
NotificationCenter.default.addObserver(
    forName: ProcessInfo.thermalStateDidChangeNotification,
    object: nil, queue: .main
) { _ in
    switch ProcessInfo.processInfo.thermalState {
    case .serious, .critical: renderer.targetFPS = 30   // 프레임·품질 낮추기
    default:                  renderer.targetFPS = 60
    }
}

import Foundation

// Apple Silicon은 성능(P) 코어와 효율(E) 코어를 함께 둔다.
// QoS는 "어느 쪽에 배치할지"의 힌트가 된다. E 코어는 전력이 훨씬 낮다.

// ✅ 사용자가 지금 기다린다 → P 코어 우선
func loadCurrentScreen() {
    Task(priority: .userInitiated) { await fetchAndRender() }
}

// ✅ 곧 필요하지만 지금 기다리진 않는다 → E 코어로 유도
func prefetchNextPage() {
    Task(priority: .utility) { await prefetch() }
}

// ✅ 사용자가 전혀 모르는 뒷정리 → 가장 낮게
let cleanupQueue = DispatchQueue(label: "com.app.cleanup", qos: .background)

func scheduleCleanup() {
    cleanupQueue.async { pruneOldCache() }
}

// ✅ 큐를 만들 때 QoS를 명시한다 — 기본값은 .default라 애매하다
let syncQueue = DispatchQueue(label: "com.app.sync", qos: .utility)

// ❌ 전부 높게 올리면 우선순위가 의미를 잃고 전력만 더 쓴다
// let everything = DispatchQueue(label: "x", qos: .userInteractive)

// ⚠️ QoS 역전 주의: 높은 QoS가 낮은 QoS의 결과를 기다리면
//    시스템이 낮은 쪽을 승격해 주지만, 세마포어로 막아 둔 경우 등
//    승격이 통하지 않는 경로가 있다. 구조 자체를 피하는 게 낫다.

// ✅ 실제 코어 배치를 확인하려면 Instruments의 CPU Counters / System Trace에서
//    스레드가 어느 코어 클러스터에서 도는지 볼 수 있다

func fetchAndRender() async {}
func prefetch() async {}
func pruneOldCache() {}

import Foundation

// 타이트 루프는 코어를 100%로 붙잡는다. 전력·발열이 급증하고
// 다른 작업까지 밀린다.

// ❌ ① busy-wait
func waitBad(until condition: () -> Bool) {
    while !condition() { }              // 💥 코어 하나를 통째로 태운다
}

// ❌ ② 짧은 간격 폴링
func pollBad() {
    Timer.scheduledTimer(withTimeInterval: 0.05, repeats: true) { _ in
        checkServerForUpdates()          // 초당 20번 — 배터리가 녹는다
    }
}

// ✅ ① 이벤트 기반으로 바꾼다
actor Signal {
    private var waiters: [CheckedContinuation<Void, Never>] = []

    func wait() async {
        await withCheckedContinuation { waiters.append($0) }   // 잠든다
    }
    func fire() {
        let current = waiters; waiters = []
        current.forEach { $0.resume() }
    }
}

// ✅ ② 서버 푸시로 (폴링 자체를 없앤다)
//    APNs silent push → application(_:didReceiveRemoteNotification:)

// ✅ ③ 폴링이 불가피하면 간격을 늘리고 leeway를 준다
func pollReasonably() {
    let timer = DispatchSource.makeTimerSource(queue: .global(qos: .utility))
    timer.schedule(deadline: .now() + 60,
                   repeating: 60,
                   leeway: .seconds(15))   // ✅ 시스템이 다른 깨우기와 묶는다
    timer.setEventHandler { checkServerForUpdates() }
    timer.resume()
}

// ✅ ④ 지수적으로 간격을 늘린다 (아무 일도 없으면 덜 자주 확인)
func adaptivePoll(idleRounds: Int) -> Duration {
    .seconds(min(pow(2.0, Double(idleRounds)) * 30, 900))   // 30초 → 최대 15분
}

func checkServerForUpdates() {}
import UIKit

import Foundation
import UIKit

// 열이 쌓이면 시스템이 주파수를 낮춘다(스로틀링). 그 전에 스스로 부하를 줄이면
// 사용자 체감 성능이 오히려 좋아진다.

@MainActor
final class PerformanceGovernor {
    private var observers: [NSObjectProtocol] = []

    func start() {
        observers.append(NotificationCenter.default.addObserver(
            forName: ProcessInfo.thermalStateDidChangeNotification,
            object: nil, queue: .main) { [weak self] _ in self?.apply() })

        observers.append(NotificationCenter.default.addObserver(
            forName: .NSProcessInfoPowerStateDidChange,
            object: nil, queue: .main) { [weak self] _ in self?.apply() })

        apply()
    }

    private func apply() {
        let info = ProcessInfo.processInfo

        if info.isLowPowerModeEnabled {
            setQuality(.minimum)
            return
        }

        switch info.thermalState {
        case .nominal:  setQuality(.maximum)
        case .fair:     setQuality(.high)
        case .serious:  setQuality(.reduced)
        case .critical: setQuality(.minimum)
        @unknown default: setQuality(.high)
        }
    }

    private func setQuality(_ level: Quality) {
        switch level {
        case .maximum:
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(minimum: 60, maximum: 120, preferred: 120)
            ImagePipeline.shared.resumePrefetch()
            VideoPlayer.shared.preferredResolution = .p1080

        case .high:
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(minimum: 30, maximum: 60, preferred: 60)

        case .reduced:
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(minimum: 20, maximum: 30, preferred: 30)
            ImagePipeline.shared.pausePrefetch()
            VideoPlayer.shared.preferredResolution = .p720

        case .minimum:
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(minimum: 10, maximum: 20, preferred: 15)
            ImagePipeline.shared.pausePrefetch()
            BackgroundSync.shared.suspend()
        }
    }

    private enum Quality { case maximum, high, reduced, minimum }
    private var displayLink: CADisplayLink?
}

enum ImagePipeline { static let shared = ImagePipelineImpl() }
struct ImagePipelineImpl { func resumePrefetch() {}; func pausePrefetch() {} }
enum VideoPlayer { static var shared = VideoPlayerImpl() }
struct VideoPlayerImpl { var preferredResolution: Resolution = .p1080
    enum Resolution { case p720, p1080 } }
enum BackgroundSync { static let shared = BackgroundSyncImpl() }
struct BackgroundSyncImpl { func suspend() {} }