È finalmente costoso

Nel caso di codice in cui è necessario eseguire una pulizia delle risorse prima di uscire da una funzione, esiste una differenza sostanziale nelle prestazioni tra questi 2 modi di farlo.

1. Pulizia della risorsa prima di ogni dichiarazione di ritorno

   void func()
   {
       login();
   
       bool ret = dosomething();
       if(ret == false)
       {
           logout();
           return;
       }
   
       ret = dosomethingelse();
       if(ret == false)
       {
           logout();
           return;
       }
   
       dootherstuff();
   
       logout();
   }

2. Pulizia della risorsa in un blocco finally

   void func()
   {
       login();
   
       try
       {
           bool ret = dosomething();
           if(ret == false)
               return;
   
           ret = dosomethingelse();
           if(ret == false)
               return;
   
           dootherstuff();
   
       }
       finally
       {
           logout();
       }
   }

Ho fatto alcuni test di base nei programmi di esempio e non sembra esserci molta differenza. Preferisco di gran lunga il finallymodo di farlo, ma mi chiedevo se ciò avrebbe causato un calo delle prestazioni in un grande progetto.

Come indicato in Quanto sono lente le eccezioni Java? si può vedere che la lentezza try {} catch {}è all'interno dell'istanza dell'eccezione stessa.

La creazione di un'eccezione recupererà l'intero stack di chiamate dal runtime ed è qui che si trova la spesa. Se non si sta creando un'eccezione, si tratta solo di un lieve aumento del tempo.

Nell'esempio fornito in questa domanda non ci sono eccezioni, non ci si aspetterebbe alcun rallentamento nel crearle - non sono create. Invece, ciò che è qui è try {} finally {}gestire la deallocazione delle risorse all'interno del blocco finally.

Quindi, per rispondere alla domanda, no, non ci sono spese di runtime reali all'interno di una try {} finally {}struttura che non utilizza eccezioni (non è inaudita, come visto). Ciò che è probabilmente costoso è il tempo di manutenzione quando si legge il codice e si vede questo stile di codice non tipico e il programmatore deve pensare che qualcosa di diverso accade in questo metodo dopo il returnprecedente ritorno alla chiamata precedente.

Come è stato menzionato, la manutenzione è un argomento per entrambi i modi di farlo. Per la cronaca, dopo considerazione, la mia preferenza sarebbe l'approccio finale.

Considera i tempi di mantenimento dell'insegnamento a qualcuno di una nuova struttura linguistica. Vedere try {} finally {}non è qualcosa che si vede spesso nel codice Java e quindi può essere fonte di confusione per le persone. C'è un certo tempo di manutenzione per l'apprendimento di strutture un po 'più avanzate in Java rispetto a ciò che le persone conoscono.

Il finally {}blocco funziona sempre . Ed è per questo che dovresti usarlo. Considera anche il tempo di manutenzione del debug dell'approccio non finalmente quando qualcuno dimentica di includere un logout al momento giusto, o lo chiama al momento improprio, o dimentica di tornare / uscire dopo averlo chiamato in modo che venga chiamato due volte. Ci sono così tanti possibili bug con questo che l'uso di try {} finally {}rende impossibile avere.

Quando si soppesano questi due costi, in termini di manutenzione è costoso non utilizzare l' try {} finally {}approccio. Mentre le persone possono cercare quanti millisecondi frazionari o istruzioni jvm aggiuntive il try {} finally {}blocco viene confrontato con l'altra versione, si deve anche considerare le ore impiegate nel debug del modo meno ideale di affrontare la deallocazione delle risorse.

Scrivi prima il codice gestibile, e preferibilmente in modo da impedire che i bug vengano scritti in seguito.

/programming/299068/how-slow-are-java-exceptions

La risposta accettata su questa domanda mostra che il wrapping di una chiamata di funzione in un blocco try catch costa meno del 5% rispetto a una chiamata di funzione semplice. In realtà, il lancio e la cattura dell'eccezione ha comportato il runtime dell'aerostato a oltre 66 volte la chiamata di funzione nuda. Quindi, se ti aspetti che il progetto dell'eccezione venga lanciato regolarmente, proverei a evitarlo (in un codice critico delle prestazioni adeguatamente profilato), tuttavia se la situazione eccezionale è rara, non è un grosso problema.

Invece di ottimizzare, pensa a cosa sta facendo il tuo codice.

L'aggiunta del blocco finally è un'implementazione diversa: significa che ti disconnetterai da ogni eccezione.

In particolare, se l'accesso genera un'eccezione, il comportamento nella seconda funzione sarà diverso dal primo.

Se il login e il logout non fanno effettivamente parte del comportamento della funzione, suggerirei che il metodo dovrebbe fare una cosa e una cosa bene:

    void func()
    {
            bool ret = dosomething();
            if(ret == false)
                return;

            ret = dosomethingelse();
            if(ret == false)
                return;

            dootherstuff();

    }

e dovrebbe essere in una funzione che è già incapsulata in un contesto che gestisce il login / logout poiché questi sembrano fondamentalmente diversi da ciò che sta facendo il tuo codice principale.

Il tuo post è taggato come Java che non conosco molto bene, ma in .net userò un blocco using per questo:

vale a dire:

    using(var loginContext = CreateLoginContext()) 
    {
            // Do all your stuff
    }

E il contesto di accesso ha un metodo Dispose che disconnetterà e pulirà le risorse.

Modifica: in realtà non ho risposto alla domanda!

Non ho prove misurabili, ma non mi aspetterei che questo sia più costoso o sicuramente non abbastanza costoso per essere degno di ottimizzazione prematura.

Lascio il resto della mia risposta perché, sebbene non risponda alla domanda, penso che sia utile per il PO.

Presupposto: stai sviluppando in codice C #.

La risposta rapida è che non vi è alcun impatto significativo sulle prestazioni dall'uso dei blocchi try / finally. Si verifica un colpo di scena quando si generano e si rilevano eccezioni.

La risposta più lunga è vedere di persona. Se osservi il codice CIL sottostante generato ( ad es. Riflettore red-gate, puoi vedere le istruzioni CIL sottostanti generate e vedere l'impatto in quel modo.

Come altri hanno già notato, il codice Ttese avrà risultati diversi, se entrambi dosomethingelseo genererà dootherstuffun'eccezione.

E sì, qualsiasi chiamata di funzione può generare un'eccezione, almeno una StackOVerflowError! Sebbene raramente sia possibile gestirli correttamente (poiché qualsiasi chiamata funzione di pulizia avrà probabilmente lo stesso problema, in alcuni casi (come ad esempio l'implementazione di blocchi) è fondamentale persino gestirlo correttamente ...