Dovresti evitare di aggiungere trame stack inutili?

0

Recentemente ho lavorato con laravel (PHP) e c'è un'opzione quando si usa il loro ORM fluente per definire le clausole che usano le chiusure. Questo ci dà due modi, funzionalmente equivalenti, per specificare una clausola where che dovrebbe essere aggiunta solo in certi casi:

Esempio 1

    $query = App::make('Vendor_Orders')->
        where(function($query) use ($admin) {
            if (!$admin) {
                $query->where('vendor_id', '=', $this->id);
            }
        })->
        get();

Esempio 2

    $query = App::make('Vendor_Orders');
    if (!$admin) {
        $query->where('vendor_id', '=', $this->id);
    }
    $query = $query->get();

Come puoi vedere, uno di questi sta usando una chiusura (e mantenendo la "fluidità"), mentre l'altro lo evita. Il mio istinto è di preferire il secondo, perché l'uso di una funzione anonima come quella è l'aggiunta di un ulteriore stack frame, che mi aspetterei di rendere il programma meno efficiente (probabilmente un residuo del mio tempo che lavoro con C). D'altra parte, il mio collega (la cui prima lingua era PHP) preferisce il primo esempio, perché evita l'uso di un secondo operatore di assegnazione, e non vede nulla di sbagliato con accumulare chiamate di funzioni extra.

Questo mi ha fatto pensare: quanti effetti ha davvero quel frame di stack in più, in un sistema moderno? Fa qualche differenza pratica se si usa una chiamata di funzione invece di un'istruzione if?

Non cerco risposte soggettive che preferisco, chiedo una sorta di fatti riguardanti l'impatto di salti non necessari - in particolare per le funzioni anonime - in linguaggi moderni e interpretati (es. PHP, Java , eccetera.). Forse anche alcune note su come questo si differenzia dalle lingue compilate della vecchia scuola.

    
posta Benubird 04.08.2014 - 17:00
fonte

2 risposte

4

Domanda interessante, ma penso davvero che ti stai avvicinando al livello sbagliato di astrazione. Stai scrivendo un'applicazione web, probabilmente verrà mantenuta da te stesso e dai colleghi che dovranno apportare modifiche al tuo codice. Il tuo primo costo da considerare è la tua produttività. Una versione del codice è più chiara dell'altra? Una versione si adatta meglio alle convenzioni e allo stile del tuo codice? Una versione è più facile da testare e refactoring?

Dopo aver preso in considerazione tutto ciò, la questione se le prestazioni sono davvero un problema. Questo è difficile per le applicazioni Web, perché le prestazioni generali di un'app possono essere influenzate da molte cose che sono fuori dal tuo controllo. Tuttavia, se riesci a testare questo codice, sarebbe una buona idea. Ma non limitarti a testare questo snippet, a elaborare un caso d'uso completo. Quindi usa un profiler per vedere se usare più o meno chiusure ha davvero un effetto complessivo sul tuo codice.

In generale, tuttavia, suggerirei che questo tipo di micro-gestione delle prestazioni ti porterà in una buca da coniglio non produttiva. Non solo è difficile (e richiede molto tempo) capire se il tuo stile di codifica sta avendo un effetto reale sull'utente finale, può essere che le prestazioni possano essere migliorate cambiando o aggiornando o riconfigurando il runtime di PHP.

Ci sono TANTE MISURE nel benchmark delle prestazioni, meglio affrontare prima i problemi di leggibilità e manutenzione.

    
risposta data 04.08.2014 - 18:24
fonte
2

L'invocazione aggiuntiva è essenzialmente banale. Evitare di fare qualcosa di meglio per evitare una chiamata di funzione è una prematura micro-ottimizzazione. Scrivi prima la leggibilità e la manutenibilità. Una volta che il programma è stato scritto, puoi eseguire il benchmark delle prestazioni e apportare modifiche da lì (e sospetto strongmente che il collo di bottiglia delle prestazioni non sia lo stack).

Parte del motivo per cui questo è così banale è che il codice chiama le funzioni molto , quindi compilatori e interpreti hanno ottimizzato molto l'interno della chiamata di una funzione. È meglio rendere il codice più leggibile e non preoccuparti così tanto dello stack.

(Continuo a dire che il secondo è migliore, ma perché è più leggibile per me.)

    
risposta data 04.08.2014 - 18:28
fonte

Leggi altre domande sui tag