C'è qualche motivo tecnico per preoccuparsi della velocità di lancio?

Per quanto ne so, non c'è motivo tecnico di preoccuparsi di questo. Ma c'è un motivo di leggibilità.

In tutte le lingue che conosco, le due più grandi differenze tra un "cast" e una funzione che converte una X in una Y sono:

1. In molti contesti il cast sarà implicito o invisibile. Un'operazione che siete disposti a lasciare per voi il compilatore di solito dovrebbe essere un dettaglio tecnico semplice, veloce e noioso che non vale la pena di forzare il programmatore a pensare. Poiché la conversione che stai descrivendo potrebbe richiedere un po 'di tempo, è importante non scrivere codice che accidentalmente fa la conversione più volte di quanto dovrebbe, e questo significa che vale la pena rendere questa conversione esplicita come qualsiasi altra chiamata di metodo.

2. Anche se il cast è "esplicito", intuitivamente un cast implica che la X e la Y sono "lo stesso" oggetto o valore, solo rappresentati in modo diverso. La conversione che stai descrivendo prende una X, recupera una serie di As e Bs e C correlati a quella X e li combina tutti in un oggetto Y. Per me, ciò significa che X e Y non sono lo stesso oggetto in alcun senso significativo.

In altre parole, la conversione che stai facendo non è quella che normalmente chiameremmo un "cast". Quindi implementalo come una normale funzione o metodo. Non per motivi di prestazioni, ma per motivi di non confusione.

Per inciso, non c'è nulla di male nel nidificare per loops. Sono un odore di codice, dato che le più istanze di loop nidificati indicano un luogo in cui sarebbero più piccoli i metodi o una struttura dati migliore o un diverso costrutto di loop come map / filter / reduce o qualche altro refactoring appropriato, ma ci sono ancora molte volte in cui i loop multipli sono semplicemente l'unico modo leggibile per completare il lavoro.

Il tuo codice richiederà probabilmente del tempo proporzionale al numero di oggetti che tocca. Se questi oggetti sono richiesti dall'utente del codice, questa volta è inevitabile. È facile dire che "i cicli annidati sono malvagi", ma se hai 10 matrici contenenti ciascuna 10 matrici, allora hai 100 elementi che devono essere convertiti.

È possibile creare un oggetto modello che memorizza solo i dati del framework di terze parti invariato e che ha metodi di accesso che passano attraverso i dati del framework e accedono a ciò che è necessario quando e solo se necessario. Dì che ottieni dati su tutti gli studenti in tutte le classi di una scuola, sono centinaia. Se tutto ciò che un chiamante desidera è il nome del decimo studente nella 21a classe, un metodo di accesso potrebbe restituire questo modo ragionevolmente attraversando i dati di terze parti.

Un altro metodo sarebbe un modello di dati che mantiene alcuni dati non convertiti e converte se necessario. Ad esempio, nel modello di dati è possibile disporre di un array di 30 classi, in cui ogni classe è costituita da dati di modello appropriati o dati di terze parti originali. Quando accedi a una classe per la prima volta e solo dopo, converti i dati di terze parti. Quindi chiedere il decimo studente nella 21a classe e l'ottavo studente nella classe 23 converte tutti gli studenti di 2 classi (ma non tutti gli studenti di tutte le classi), e chiedere a tutti gli altri studenti nelle stesse due classi sarà veloce.

In un lavoro batch, tutto ciò non ha importanza.

In alcune circostanze, il casting non ha una limitazione tecnica che si verifica entro un certo periodo di tempo. Poi ci sono alcune API definite con timeout incorporati o presunti.

Tuttavia, quando si tratta di utenti, c'è solo una certa dose di pazienza che permetteranno. Una trasmissione più rapida comporterà meno tempo per l'utente che deve attendere il completamento di un processo.

Nella mia esperienza, un cast abbastanza veloce che l'utente non nota non ha bisogno di essere ottimizzato. Se lanci migliaia di volte per operazione, allora potrebbe avere bisogno di guardare all'efficienza. Se il cast si verifica solo poche volte per operazione, allora stai iniziando a entrare nella micro-ottimizzazione a cui gnat fa riferimento.