Rails - L'uso delle parziali rallenta il rendering delle viste?

Non conosco differenze significative nelle prestazioni di rendering tra molti partial e una singola vista quando rendi lo stesso contenuto .

Ovviamente, se esegui il rendering solo di alcuni partial in alcuni casi e altri in altri casi, riducendo così efficacemente il volume di rendering di una vista specifica, potresti guadagnare un po 'di velocità.

D'altra parte, ho sempre considerato le astrazioni parziali che dovrebbero essere utilizzate almeno da 2 luoghi diversi per giustificare la loro esistenza. L'altro motivo per usare i partial è quando vuoi rendere la stessa vista ma caricare parziali diversi in base a qualche logica di business che hai.

UPDATE:

Non posso offrire una misurazione o numeri concreti sulla velocità di rendering. Se si usa un partial in una vista, per renderlo si chiama il metodo render, quindi c'è una seconda chiamata di metodo. Questo, come ho detto nella mia risposta, non è quasi nulla, ma può aiutare a velocizzare le cose un po '.

Tuttavia non ho mai sentito di un progetto che risolva il problema delle sue prestazioni rimuovendo i partial. I partial sono un buon modo per offrire un meccanismo di riutilizzo alle viste e dalla vista dei programmatori dovrebbero essere usati per quell'ambito. Dovrebbero essere astrazioni per concetti comuni nelle viste.

Ho lavorato a un progetto in cui le parziali erano eccessivamente utilizzate. Non Rails, ma gli stessi principi MVC. Usare piccoli partial per tutto ciò che puoi immaginare li rende difficili da trovare quando inizi ad averne decine. Dove vorresti inserire un input da modificare? Nella vista? In un parziale? In quale parziale, ci sono 4 partial per questa vista? ...

Dopo alcuni rigidi aggiustamenti, con ogni aggiornamento di una vista, abbiamo rimosso i parziali non necessari. Non sono scomparsi completamente, ma ciò che restava sono le astrazioni che sono ben definite per il progetto. Rappresentano elementi ben compresi (come un albero per alcuni tipi di oggetti o un tipo di elenco specifico) che si ripetono in una forma o in un'altra su più viste. So che se vedo un albero esiste un parziale per quello. So quando vedo un certo tipo di elenco che c'è un parziale per quello. Non li ho cacciati.

La leggibilità del codice è la cosa più importante che si possa fare per un codice di base del software.

Non sono d'accordo con entrambe le risposte. Ho copiato e incollato il codice da una parte nella posizione in cui è presente nella vista parente parziale e con 500 iterazioni, questo richiede un tempo di rendering di 600ms al largo del tempo impiegato per rendere la vista. <% = rendering xyz% > è a mio parere molto rotto.

Esempio, tempo totale per il rendering della vista:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

A cura

Ho finito con l'UNDRYing di tutti i _partials all'interno del _model partial e l'ho ridotto a ~ 2000ms, a quel punto ho provato a spostare _model partial nell'indice, ma questo NON ha avuto alcun effetto sui tempi di rendering quindi suppongo che sia con le chiamate a render annidato che lo fa.

Non un ragazzo di rotaie, ma le Viste Parziali non sono probabilmente il problema di per sé. Piuttosto, sembra che tu stia facendo un po 'di SELECT N + 1. Guarda le cose dal punto di vista del server DB per assicurarti di non ridurlo in poltiglia.

Lavorare su un'app Rails 4.2 in questo momento in cui un'azione rallentata richiedeva in media circa 745 ms.

Quando rimuovo il codice dai partial e lo metto nel template principale, il tempo richiesto è in media meno di 25ms.

Il numero di chiamate per il rendering delle parziali era solo 29.

Anche se hai no n + 1 problema e fai tutto il database in primo piano (ad esempio con un CTE ricorsivo), i partial primati sono ancora molto lenti. Haml ed Erb sembrano entrambi lenti. On Rails 5.1.4 Sto vedendo alcuni millisecondi per ogni partial, più occasionali partial che sono molto peggio (probabilmente corrisponde alla garbage collection).

Ho notato che se rinominare il partial mentre una di queste richieste è in esecuzione, ricevo immediatamente un errore su come il file non viene trovato. Quindi apparentemente Rails sta leggendo il partial off disk, riorganizzandolo e valutandolo per ogni iterazione. Non c'è da stupirsi che sia lento!

Gran parte della lentezza che si riscontra nei partial parziali avviene solo durante lo sviluppo. Passa alla produzione per testare.