Supongamos que tenemos el siguiente código que define un bucle continuo (como en un juego):
let queue = DispatchQueue(label: "DemoSerialQueue") let workItem = DispatchWorkItem{ print("Hello World") } func gameLoop() { queue.async(execute:workItem) }¿Sería el código anterior más eficiente en términos de velocidad que el siguiente?
func gameLoop() { queue.async{ print("Hello World") } }En particular, me pregunto si la segunda forma asignaría un cierre en cada bucle y, por lo tanto, provocaría un impacto en el rendimiento.
La clase DispatchWorkItem es un resumen del concepto de elemento de trabajo. Hay pocos beneficios.
Un elemento de trabajo de envío tiene un indicador de cancelación. Si se cancela antes de ejecutarse, la cola de despacho no lo ejecutará y lo omitirá. Si se cancela durante su ejecución, la propiedad cancel devuelve True. En ese caso, podemos abortar la ejecución.
Al encapsular nuestro código de solicitud en un elemento de trabajo, podemos cancelarlo fácilmente cada vez que se reemplaza por uno nuevo, como este:
class SearchViewController: UIViewController, UISearchBarDelegate { // We keep track of the pending work item as a property private var pendingRequestWorkItem: DispatchWorkItem? func searchBar(_ searchBar: UISearchBar, textDidChange searchText: String) { // Cancel the currently pending item pendingRequestWorkItem?.cancel() // Wrap our request in a work item let requestWorkItem = DispatchWorkItem { [weak self] in self?.resultsLoader.loadResults(forQuery: searchText) } // Save the new work item and execute it after 250 ms pendingRequestWorkItem = requestWorkItem DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(250), execute: requestWorkItem) } }En general, las funciones de Dispatch pueden tomar un bloque o un DispatchWorkItem como parámetro. Por lo tanto, no habrá ningún impacto en el rendimiento ya que usamos bloques en ambos casos . Usa el que más te convenga.