Il presente articolo è stato tradotto automaticamente.

CLR

Panoramica dei miglioramenti delle prestazioni in .NET 4.5

Ashwin Kamath

 

Questo articolo discute la versione non definitiva di Microsoft.NET Framework 4.5. Tutte le relative informazioni sono soggette a modifiche.

Su Microsoft.Squadra NET Framework, noi abbiamo sempre capito che il miglioramento delle prestazioni è almeno lo stesso valore agli sviluppatori come l'aggiunta di nuove funzionalità di runtime e libreria di API. I.NET Framework 4.5 include investimenti significativi in termini di prestazioni, beneficiando di tutti gli scenari di applicazione. Inoltre, perché.NET 4.5 è un aggiornamento per.NET 4, anche tuo.NET 4 applicazioni possono godere di molti dei miglioramenti di prestazioni esistenti.NET 4 caratteristiche.

Quando si tratta di consentendo agli sviluppatori di offrire esperienze di applicazione soddisfacente, tempo di avvio (vedere msdn.microsoft.com/magazine/cc337892), l'utilizzo della memoria (vedere msdn.microsoft.com/magazine/dd882521), velocità di trasmissione e la reattività contano veramente. Abbiamo impostato gli obiettivi il miglioramento di queste metriche per gli scenari di applicazione diversa, e poi abbiamo progettare cambiamenti per soddisfare o superare loro. In questo articolo, provvederemo a fornire una panoramica di alcuni dei miglioramenti di prestazioni chiave abbiamo fatto nei.NET Framework 4.5.

CLR

In questa versione, ci siamo concentrati sulla: sfruttando più core di processore per migliorare le prestazioni, ridurre la latenza nel garbage collector e migliorare la qualità del codice delle immagini native. Di seguito sono alcune delle caratteristiche di miglioramento di prestazioni chiave.

Multi-core Just-in-Time (JIT) si continuamente monitorare i progressi di hardware a basso livello e lavorare con i fornitori di chip per ottenere prestazioni ottimali assistita da hardware. In particolare, abbiamo avuto chip multi-core nei nostri laboratori di prestazioni dal momento che erano disponibili e hanno apportato modifiche adeguate per sfruttare tale cambiamento specifico hardware; Tuttavia, tali modifiche hanno beneficiato molto pochi i clienti in un primo momento.

A questo punto, quasi ogni PC ha almeno due core, tale che nuove funzionalità che richiedono più di un nucleo immediatamente sono ampiamente utile. All'inizio dello sviluppo di.NET 4.5, abbiamo deciso di stabilire se è ragionevole utilizzare più core di processore per condividere il compito di compilazione JIT — in particolare nell'ambito di avvio dell'applicazione — per velocizzare l'esperienza complessiva. Nell'ambito di tale inchiesta, abbiamo scoperto che è abbastanza riuscito apps hanno un numero di soglia minima di compilazione JIT metodi per rendere l'investimento vale la pena.

La funzionalità di opera di metodi suscettibili di essere eseguito su un thread in background, che su una macchina multi-core verrà eseguito su un altro nucleo, in parallelo la compilazione JIT. Nel caso ideale, il secondo nucleo rapidamente ottiene davanti la linea principale di esecuzione dell'applicazione, così la maggior parte dei metodi sono JIT compilato con il tempo che sono necessarie. Per sapere quali metodi per la compilazione, la funzionalità genera dati di profilo che tiene traccia dei metodi che vengono eseguiti e poi è guidata da questo profilo dati su una fase più tardi. Questa esigenza di generare i dati del profilo è il modo principale in cui interagire con questa caratteristica.

Con un minimo aggiunta di codice, è possibile utilizzare questa funzionalità di runtime per migliorare in modo significativo i tempi di avvio di siti Web e applicazioni client. In particolare, è necessario effettuare chiamate semplice a due metodi statici della classe ProfileOptimization, nello spazio dei nomi System. Runtime. Vedere la documentazione MSDN per ulteriori informazioni. Si noti che questa funzionalità è attivata per impostazione predefinita per le applicazioni ASP.NET 4.5 applicazioni e applicazioni Silverlight 5.

Immagini Native ottimizzate per diversi rilasci, abbiamo abilitato di precompilare il codice per immagini native con uno strumento chiamato generazione di immagini Native (NGen). In genere le immagini native conseguente risultato significativamente più veloce avvio dell'applicazione non è vista con compilazione JIT. In questa release abbiamo introdotto uno strumento supplementare chiamato gestito profilo Guided Optimization (MPGO), che consente di ottimizzare il layout delle immagini native per prestazioni superiori. MPGO utilizza una tecnologia di ottimizzazione PGO, molto simile nel concetto multicore che JIT descritto in precedenza. I dati del profilo dell'applicazione includono un scenario rappresentanza o una serie di scenari, che può essere utilizzato per riordinare il layout di un'immagine nativa, tale che i metodi e le altre strutture di dati necessari all'avvio sono colocated densamente all'interno di una parte dell'immagine nativa, con conseguente nel più breve tempo di avvio e meno working set (utilizzo della memoria di un'applicazione). Nel nostro test e l'esperienza, vediamo in genere un beneficio dal MPGO con applicazioni gestite più grandi (ad esempio, grandi GUI applicazioni interattive) e si consiglia l'uso in gran parte lungo queste linee.

Lo strumento MPGO genera dati di profilo per un linguaggio intermedio (IL) DLL e aggiunge il profilo come risorsa DLL IL. Lo strumento NGen viene utilizzato per precompilare IL DLLs dopo la profilazione, ed esegue ulteriore ottimizzazione per la presenza dei dati di profilo. Figura 1 Visualizza il flusso del processo.

Figura 1 flusso del processo con lo strumento MPGO

Grande oggetto Heap (LOH) allocatore molti.Gli sviluppatori netti ha chiesto una soluzione per il problema della frammentazione LOH o un modo per forzare la compattazione della LOH. Si può leggere di più su come il LOH funziona nel giugno 2008 CLR Inside Out colonna da Maoni Stephens a msdn.microsoft.com/magazine/cc534993. Per riassumere, qualsiasi oggetto di dimensioni 85.000 byte o più ottiene allocato sul LOH. Attualmente, non è compattato il LOH. Compattando il LOH consumerebbe un sacco di tempo perché il garbage collector avrebbe dovuto spostare oggetti di grandi dimensioni e, quindi, è una proposizione costosa. Quando gli oggetti sul LOH ottenere raccolti, lascia liberi spazi tra gli oggetti che sopravvivono la raccolta, che conduce alla questione della frammentazione.

Per spiegare un po' più, CLR effettua una lista libera fuori degli oggetti morti, permettendo loro di essere riutilizzati in seguito per soddisfare le richieste di allocazione di oggetti di grandi dimensioni; oggetti inattivi adiacenti sono realizzati in un unico oggetto gratis. Alla fine un programma può finire in una situazione dove questi frammenti di memoria libera tra oggetti di grandi dimensioni dal vivo non sono abbastanza grandi per fare ulteriori allocazioni di oggetto nel LOH, e perché la compattazione non è un'opzione, abbiamo rapidamente incorrere in problemi. Ciò conduce ad applicazioni diventando insensibile e porta infine ad eccezioni di memoria esaurita.

In.NET 4.5 abbiamo fatto alcune modifiche per rendere efficiente l'uso di frammenti di memoria in LOH, soprattutto per quanto riguarda il modo in cui gestiamo la lista gratuita. Le modifiche si applicano a sia workstation e server garbage collection (GC). Si prega di notare che questo non cambia il limite di 85.000 byte per oggetti LOH.

Sfondo GC per Server In.NET 4 abbiamo attivato sfondo GC per workstation GC. Da allora, abbiamo visto che una maggiore frequenza di macchine con estremità superiore dell'heap dimensioni che vanno dai pochi gigabyte per decine di gigabyte. Persino un collezionista parallelo ottimizzato come la nostra può prendere secondi per raccogliere tali grandi cumuli, bloccando così thread delle applicazioni per secondi. Sfondo GC per server introduce il supporto per le collezioni contemporanee al nostro raccoglitore di server. Minimizza il blocchi lungo collezioni pur continuando a mantenere la velocità effettiva applicazione alta.

Se si utilizza server GC, non dovete fare nulla per approfittare di questa nuova caratteristica; sullo sfondo di server GC avverrà automaticamente. Le caratteristiche di GC ad alto livello di sfondo sono le stesse per client e server GC:

• Solo completo GC (generazione 2) può capitare in background.
• Sfondo GC non compatta.
• In primo piano GC (generazione 0/generazione 1 GC) può accadere durante sfondo GC. Server GC è fatto sui thread di GC server dedicato.
• GC pieno di blocco avviene anche sui thread di GC server dedicato.

Programmazione asincrona

Un nuovo modello di programmazione asincrono è stato introdotto come parte della Visual Studio Async CTP e ora è una parte importante del.NET 4.5. Queste nuove funzionalità del linguaggio in.4.5 NET consentono di produttivamente scrivere codice asincrono. Due parole chiave del linguaggio nuovo in c# e Visual Basic chiamato "async" e "attendono" attivare questo nuovo modello. .4.5 NET è anche stato aggiornato per supportare applicazioni asincrone che utilizzano queste nuove parole chiave.

Il portale di programmazione asincrona di Visual Studio su MSDN (msdn.microsoft.com/vstudio/async) è una grande risorsa per campioni, white paper e colloqui sul supporto e nuove funzionalità del linguaggio.

Librerie di calcolo parallelo

Una serie di miglioramenti furono fatti per le biblioteche (tributo) di calcolo parallelo.NET 4.5 per migliorare le API esistenti.

Peso leggero più velocemente le attività le System.Threading.Tasks.Task e le attività <TResult> classi sono state ottimizzate per utilizzare meno memoria ed eseguire più velocemente negli scenari chiavi. In particolare, casi relativi alla creazione di attività e pianificazione continuazioni visto miglioramenti delle prestazioni fino al 60 per cento.

Più PLINQ le query eseguite in parallelo PLINQ precipitano l'esecuzione sequenziale quando pensa che sarebbe fare più danni (rendono le cose più lente) da parallelizzazione di una query. Queste decisioni sono educato congetture e non sempre perfetta e in.NET 4.5, PLINQ riconoscerà più classi delle query che esso può parallelizzare con successo.

Numero di collezioni contemporanee a più veloce di ritocchi sono state fatte per System.Collections.Concurrent.ConcurrentDictionary < TKey, TValue > per renderlo più veloce per determinati scenari.

Per maggiori informazioni su queste modifiche, controllare il blog del team Parallel Computing Platform in blogs.msdn.com/b/pfxteam.

(ADO.NET),

Dati Bit compressione Row supporto Null Null sono comuni soprattutto per i clienti sfruttando la funzionalità di SQL Server 2008 colonne di tipo sparse. I clienti sfruttando la funzionalità di colonne di tipo sparse potenzialmente in grado di produrre i risultati che contengono un gran numero di colonne null. Per questo scenario, è stata introdotta la riga null--compressione a bit (token di SQLNBCROW o, semplicemente, NBCROW). Questo riduce lo spazio utilizzato per le righe di imposta risultanti inviate dal server con un gran numero di colonne da comprimere colonne multiple con valori NULL in una maschera di bit. Ciò contribuisce in modo significativo a compressione del protocollo tabular data stream (TDS) dei dati dove ci sono molte colonne annullati nei dati.

Entity Framework

Auto-compilato LINQ query quando si scrive un LINQ per eseguire una query entità oggi, Entity Framework cammina sopra la struttura ad albero dell'espressione generato da c# / Visual Basic compiler e si traduce (o compila) che in SQL, come mostrato nella Figura 2.

Figura 2 Query LINQ to Entities tradotto in SQL

Compilare la struttura ad albero dell'espressione in SQL coinvolge overhead, però, in particolare per le query più complesse. Nelle versioni precedenti di Entity Framework, se si voleva evitare di dover pagare questa riduzione delle prestazioni, ogni volta che è stata eseguita una query LINQ, era necessario utilizzare la classe CompiledQuery.

Questa nuova versione di Entity Framework supporta una nuova funzionalità chiamata Auto-Compiled query LINQ. Ora ogni query LINQ to Entities eseguite automaticamente viene compilato e inseriti nella cache dei piani di query Entity Framework. Ogni volta che si esegue la query aggiuntiva Entity Framework troveranno nella sua cache delle query e non dovrete andare attraverso il processo di compilazione tutto di nuovo. Si può leggere di più su di esso a bit.ly/iCaM2b.

Windows Communication Foundation e Windows Workflow Foundation

Il team di Windows Communication Foundation (WCF) e Windows Workflow Foundation (WF) ha anche fatto un mucchio di miglioramenti delle prestazioni in questa versione, come ad esempio:

• Miglioramenti di scalabilità TCP attivazione: I clienti segnalati un problema con l'attivazione di TCP, tale che quando molti utenti simultanei inviato richieste con le riconnessioni costante, il servizio di condivisione delle porte TCP non scalabilità. Questo è stato risolto.NET 4.5.
• Supporto incorporato compressione GZip per WCF HTTP/TCP: Con questa nuova compressione, ci aspettiamo che fino a un rapporto di compressione 5x.
• Quando l'utilizzo della memoria è alta per WCF di riciclaggio ospitante: Quando l'utilizzo della memoria è alta (configurabile manopola), usiamo meno utilizzato di recente (LRU) logica a riciclare i servizi WCF.
• HTTP async supporto per WCF in streaming: Abbiamo implementato questa funzionalità.NET 4,5 e raggiunto la stessa velocità di trasmissione come quella di streaming sincrono ma con molto migliore scalabilità.
• Miglioramenti di frammentazione di generazione 0 per WCF TCP.
• BufferManager ottimizzato per WCF per oggetti di grandi dimensioni: Per gli oggetti di grandi dimensioni, meglio pool di buffer è stato implementato per evitare i costi di generazione ad alta 2 GC.
• Miglioramento di convalida WF con espressione nella cache: Ci aspettiamo fino a 3 miglioramenti x per uno scenario di nucleo di caricamento WF ed eseguirlo.
• Implementate WCF/WF-to-end Event Tracing for Windows (ETW): Anche se questo non è una caratteristica di miglioramento delle prestazioni, aiuta i clienti sulle indagini di prestazioni.

Si possono trovare maggiori dettagli sul blog di flusso di lavoro a blogs.msdn.com/b/workflowteam e l'articolo di MSDN Library al bit.ly/n5VCtU.

ASP.NET,

Migliorare la densità del sito (anche definito come "consumo di memoria per sito") e il tempo di avvio a freddo dei siti di hosting condiviso sono stati due obiettivi di prestazione chiave per l'applicazione ASP.NET team per.NET 4.5.

In scenari di hosting condivisi, molti siti condividono la stessa macchina. In questi ambienti, il traffico è solitamente basso. I dati forniti da alcuni hosting spettacoli di compagnie che la maggior parte del tempo che la richiesta al secondo è inferiore a 1 rps, con punte occasionali di rps 2 o più. Questo significa che molti processi di lavoro probabilmente morirà quando sono inattivi per un lungo periodo (20 minuti per impostazione predefinita in IIS 7 e versioni successive). Quindi il tempo di avvio diventa molto importante. In ASP.NET, che è il tempo che impiega un sito Web per ricevere una richiesta e rispondere ad esso, durante il processo di lavoro è sceso rispetto a quando il sito Web è stato già compilato.

Abbiamo implementato diverse caratteristiche in questa release per migliorare il tempo di avvio per gli scenari di hosting condivisi. Le caratteristiche utilizzate sono:

• Bin assembly internato (assemblies comune condivisione): L'ASP.NET ombra copia funzionalità consente gli assembly che vengono utilizzati in un dominio applicazione per essere aggiornato senza scarico quel AppDomain (necessarie perché il CLR blocca gli assembly che vengono utilizzati). Questo viene fatto copiando assembly dell'applicazione in un percorso diverso (una posizione predefinita determinata CLR o uno specificato dall'utente) e caricamento di assembly da quella posizione. In questo modo l'assembly originale essere aggiornato, mentre la copia shadow è bloccata. ASP.NET attiva questa funzione per impostazione predefinita per gli assembly di cartella Bin affinché le dll possono continuare ad essere aggiornati mentre un sito è attivo e funzionante.
• ASP.NET riconosce nella cartella Bin di un sito Web come una cartella speciale per assembly (dll) per ASP personalizzato.Controlli netti, componenti o altro codice che deve essere presente in una pagina ASP.NET applicazione e condivise attraverso varie pagine del sito. Un assembly compilato nella cartella Bin ottiene automaticamente riferimento ovunque nell'applicazione Web. ASP.NET rileva anche l'ultima versione di una DLL specifica nella cartella Bin per l'uso presenti sul sito Web. Applicazioni preconfezionate destinati ad essere utilizzati da ASP.NET siti installare in genere nella cartella Bin, piuttosto che nella Global Assembly Cache.
• L'ASP.NET e CLR squadre hanno scoperto che quando molti siti risiedono sullo stesso server e utilizzano l'applicazione stessa, molti di questi copia shadow DLLs tendono ad essere esattamente lo stesso. Questi file vengono letti dal disco e caricati in memoria, questo porta a molti carichi ridondanti che aumentano il consumo di memoria e tempo di avvio. Abbiamo lavorato su usando il link simbolico per il CLR di seguire e poi AP­attuate identificazione del comune di file e li internato in una posizione speciale (per i collegamenti simbolici punterà). ASP.NET configura automaticamente ombra copia per Bin dll per essere su. Hoster condiviso ora impostare loro macchine secondo di ASP.NETTI orientamenti per il beneficio di ottenere il massimo rendimento.
• JIT multi-core: Vedere informazioni correlate nella sezione precedente "CLR". L'ASP.NET team utilizza la funzionalità JIT multi-core per migliorare il tempo di avvio da diffondere la compilazione JIT attraverso core del processore. Questa opzione è attivata per impostazione predefinita in ASP.NET, quindi è possibile usufruire di questa funzionalità senza ulteriori operazioni. È possibile disattivare utilizzando la seguente impostazione nel file Web. config:

<configuration> <!-- ...
--> <system.web> <compilation profileGuidedOptimizations="None" /> <!-- ...
-->

• Prefetcher: Tecnologia Prefetcher in Windows è molto efficacia nel ridurre il disco leggere il costo di paging durante l'avvio dell'applicazione. Prefetcher è ora attivato (ma non per impostazione predefinita) su Windows Server pure. Per abilitare la Prefetcher per l'hosting Web ad alta densità, eseguire il seguente set di comandi nella riga di comando:

sc config sysmain start=auto reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 2 /f reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /f net start sysmain

• Si può quindi aggiornare il file Web. config di utilizzarlo in ASP.NET:

<configuration> <!-- ...
--> <system.web> <compilation enablePrefetchOptimization   ="true" /> <!-- ...
-->

• Tuning GC per ad alta densità di Web hosting: GC può urtare il consumo di memoria di un sito, ma esso può essere sintonizzato per consentire prestazioni migliori. È possibile ottimizzare o configurare GC per migliorare le prestazioni della CPU (rallentamento della frequenza delle collezioni) o basso consumo di memoria (cioè, più frequente raccolte per liberare memoria più presto). Per abilitare il GC ottimizzazione, è possibile selezionare l'impostazione HighDensityWebHosting nel file Aspnet. config nella cartella Windows\Microsoft\v4.0.30319 a conseguire minore consumo di memoria (working set) per ogni sito:

<configuration> <!-- ...
--> <runtime> <performanceScenario   value="HighDensityWebHosting" />   <!-- ...
-->

Maggiori dettagli su ASP.Miglioramenti delle prestazioni di rete possono essere trovati in "come iniziare con la prossima versione di ASP.NET"white paper al bit.ly/A66I7R.

Retroazione ha voluto

L'elenco qui presentata non è esaustiva. Ci sono più piccole modifiche per migliorare le prestazioni che sono state omesse per mantenere la portata di questo articolo è limitato alle funzionalità principali. Oltre a questo, il.NET Framework prestazioni squadre sono stati impegnati nella miglioramenti delle prestazioni specifici per applicazioni in stile Metro Windows 8 gestito. Una volta che potete scaricare e provare la.NET Framework 4.5 e Visual Studio 11 beta per Windows 8, fatecelo sapere se avete commenti o suggerimenti per i rilasci avanti.

Glossario

**Hosting condiviso:**Conosciuto anche come "hosting Web condiviso," ad alta densità di Web hosting consente a centinaia, se non migliaia — di siti Web per l'esecuzione sullo stesso server. Condividendo i costi dell'hardware, ogni sito può essere mantenuto per un costo inferiore. Questa tecnica ha notevolmente abbassato la barriera all'ingresso per i proprietari di siti Web.

**Avvio a freddo:**Avvio a freddo è il tempo necessario per lanciare quando l'applicazione non era già presente in memoria. L'esperienza di avvio a freddo avviando un'applicazione dopo un riavvio del sistema. Per le applicazioni di grandi dimensioni, avvio a freddo può richiedere diversi secondi perché le pagine richieste (codice, dati statici, del Registro di sistema e così via) non sono presenti in memoria e disco costoso accessi sono tenuti a portare le pagine nella memoria.

**Avvio a caldo:**Avvio a caldo è il tempo necessario per avviare un'applicazione che è già presente in memoria. Ad esempio, se un'applicazione è stata lanciata pochi secondi all'inizio, è probabile che la maggior parte delle pagine sono già caricata in memoria e l'OS riutilizzerà loro, risparmio di tempo di accesso al disco costoso. Questo è il motivo per cui un'applicazione è molto più veloce per avviare la seconda volta che si esegue (o perché un secondo.NET app inizia più veloce rispetto a prima, perché parti di.NET sarà già caricato in memoria).

**Generazione delle immagini native o NGen:**Si riferisce al processo di precompilazione eseguibili Intermediate Language (IL) in codice macchina prima di tempo di esecuzione. Questo si traduce in due primari di migliorare le prestazioni. In primo luogo, riduce il tempo di avvio applicazione evitando la necessità di compilare codice in fase di esecuzione. In secondo luogo, migliora l'utilizzo della memoria permettendo per le pagine di codice essere condivisi tra più processi. C'è anche uno strumento di Ngen. exe, che crea immagini native e li installa in Native Image Cache (NIC) sul computer locale. Il runtime carica immagini native quando sono disponibili.

**Profile Guided Optimization:**Ottimizzazione PGO ha dimostrato di migliorare l'avvio e tempi di esecuzione delle applicazioni native e gestite. Windows fornisce la casella degli strumenti e delle infrastrutture per eseguire il profilo guidate ottimizzazione per gli assembly nativi, considerando che Common Language Runtime fornisce l'infrastruttura per eseguire PGO per assembly gestiti (chiamato gestito ottimizzazione PGO, o MPGO) e un set di strumenti. Queste tecnologie sono utilizzate da molte squadre all'interno di Microsoft per migliorare le prestazioni delle loro applicazioni. Ad esempio, Common Language Runtime esegue ottimizzazione PGO di assembly nativo (ottimizzazione PGO C++) e assembly gestiti (tramite MPGO).

**Garbage Collector:**I.NET runtime supporta la gestione automatica della memoria. Si tiene traccia di ogni allocazione di memoria realizzati dal programma gestito e chiama periodicamente un garbage collector che trova la memoria non è più in uso e riutilizza per nuove allocazioni. Un'ottimizzazione importante che esegue il garbage collector è che non cerca l'intero heap ogni volta, ma piuttosto partizioni heap in tre generazioni (generazione 0, generazione 1 e generazione 2). Per ulteriori informazioni su garbage collector, si prega di leggere il giugno 2009 colonna CLR Inside Out a msdn.microsoft.com/magazine/dd882521.

**Compattazione:**Nell'ambito della procedura di garbage collection, quando l'heap raggiunge uno stato dove è sufficientemente frammentata, il garbage collector comprime l'heap spostando oggetti dal vivo vicino a vicenda. L'obiettivo primario di compattazione dell'heap è quello di rendere disponibili in cui allocare oggetti più grandi blocchi di memoria.

Ashwin Kamath è program manager del team di CLR.NET e ha guidato le caratteristiche di prestazioni e affidabilità per il.NET Framework 4.5. Attualmente sta lavorando sulle funzionalità di diagnostica per la piattaforma di sviluppo Windows Phone.

Grazie ai seguenti esperti tecnici per la revisione di questo articolo: Surupa Biswas, Eric Dettinger, Wenlong Dong, Layla Driscoll, Dave Hiniker, Piyush Joshi, Ashok Kamath, Richard Lander, Vance Morrison, Subramanian Ramaswamy, Jose Reyes, Danny Shih e Bill Wert