2015-02-19 15 views
8

Quali sono i diversi costi di runtime sostenuti dai seguenti tipi di cast?Qual è il costo di runtime dei lanci di Swift?

  1. numerico cast di costante, ad es .:

    let f = 0.1 as CGFloat 
    

    mi piacerebbe immaginare questo ha un costo di esecuzione pari a zero.

  2. numerico cast del valore di runtime, ad es .:

    let f = someDoubleValue as CGFloat 
    

    Mi piacerebbe immaginare questo ha un costo estremamente ridotto tempo di esecuzione.

  3. upcast, ad es .:

    let dict: [String: Int] = ... 
    let anyObj = dict as AnyObject 
    

    mi aspetto questo per avere costi di esecuzione pari a zero.

  4. Failable Downcast, ad es .:

    let anyObj: AnyObject = ... 
    if let str = anyObj as? String { ... } 
    

    mi aspetto questo per avere un costo di esecuzione proporzionale al numero di classi nella gerarchia di tipo dinamico di anyObj.

  5. forzata Downcast, ad es .:

    let anyObj: AnyObject = ... 
    let str = anyObj as! String 
    

    Forse il costo per un downcast forzata è leggermente inferiore?

  6. forzato Downcast di raccolta, ad es .:

    let dates: [AnyObject] = ... 
    for date in dates as! [NSDate] { ... } 
    

    Cosa succede qui - soprattutto quando si proviene da un datesNSArray? Il costo di esecuzione di questo cast è proporzionale al numero dei suoi elementi? Cosa succede se lancio su un tipo di raccolta più complesso come [String: [String: [Int]]] - l'intera raccolta è attraversata per assicurarsi che tutti i suoi elementi e sottoelementi siano conformi a questo cast?

Per ciascuno dei primi quattro casi, le mie affermazioni sono vere?

+1

Credo che ci sono troppe risposte possibili e corrette alle vostre numerose domande. Per esempio. il tuo no 2: un ottimizzatore può rilevare come 'f' è usato e se l'architettura della macchina si adatta può semplicemente usare' someDoubleValue' direttamente come 'Double' mentre in altri casi deve copiare il valore in qualche memoria extra. Nel caso in cui avrà bisogno di memoria in quanto potrebbe mantenere tutto nei registri. Se la prestazione in questi casi è in discussione: creare un punto di riferimento. –

+0

Come ho capito, il n. 3 non è davvero un esempio upcast, perché il dizionario veloce è una struttura e quando lo si "lancia" su AnyObject, swift in realtà crea NSDictionary. Questo deve essere lo stesso per Int -> NSNumber, String -> NSString e altri –

risposta

11
  • è O (1) (quasi 0) se è ovviamente calcinabile (come colata numerica e upcasting): caso 1, 2, 3.

  • Per gli altri getti non Collection, ovviamente è O (1): il caso 4, 5.

  • Per downcastings raccolta:

    • as? è O (n) per tipo di elemento controllo viene eseguito avidamente.
    • nativo downcasting forzata è O (1) perché il tipo elemento di riscontro è differito: cassa 6.
    • Bridged costretto downcasting (NSArray as! [NSDate]) è O (n) per tipo di elemento controllo viene eseguito avidamente.
    • Le raccolte nidificate vengono convertite in modo ricorsivo, quindi è sufficiente applicare le regole precedenti in modo ricorsivo.

Fonti:

  1. https://github.com/apple/swift/blob/master/stdlib/public/runtime/Casting.cpp
  2. https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift
  3. https://github.com/apple/swift/blob/master/stdlib/public/core/HashedCollections.swift.gyb
+0

Ottima risposta, grazie per aver esaminato attentamente questo argomento. –

Problemi correlati