View Full Version : Codice nel try meno performante?
Ciao, esiste qualche differenza nel tempi di esecuzione del codice in un una struttura try? Dovrebbero esserci per forza, perché altrimenti non avrebbe senso inserire solo alcune parti di codice ma tutto il programma e dovrebbe essere previsto di default, senza nemmeno essere esplicitato.
The_ouroboros
08-03-2013, 14:23
Ciao, esiste qualche differenza nel tempi di esecuzione del codice in un una struttura try? Dovrebbero esserci per forza, perché altrimenti non avrebbe senso inserire solo alcune parti di codice ma tutto il programma e dovrebbe essere previsto di default, senza nemmeno essere esplicitato.
l'overhead eventuale è nulla rispetto ai vantaggi :D
l'overhead eventuale è nulla rispetto ai vantaggi :D
Quindi scrivere tutto il programma in un try sarebbe una buona abitudine di programmazione?
The_ouroboros
08-03-2013, 14:56
Quindi scrivere tutto il programma in un try sarebbe una buona abitudine di programmazione?
no, ma non stare li a farsi patemi sull'overhead di questo costrutto? sì :)
clockover
08-03-2013, 15:03
Se non è necessario il blocco try/catch non ci sono motivi per inserirlo
StackOverflow come sempre ha delle risposte a quasi tutto --> http://stackoverflow.com/questions/10169671/java-overhead-of-entering-using-try-catch-blocks
Quasi sicuramente ci sono altre risorse in rete e anche meglio approfondite
Qui invece un piccolo bench --> http://stackoverflow.com/questions/10169671/java-overhead-of-entering-using-try-catch-blocks
Ps
comunque secondo me è proprio una pippa mentale pensare all'overhead del try/catch
The_ouroboros
08-03-2013, 15:05
ovviamente intendevo usarlo dove serve e non tanto per usarlo.
clockover
08-03-2013, 15:12
ovviamente intendevo usarlo dove serve e non tanto per usarlo.
infatti :) oggi non riesco a esprimermi... ho bisogno di dormire :muro:
sottovento
08-03-2013, 21:34
In effetti il discorso e' lungo.
Il problema principale e' che in caso di eccezione si deve effettuare il rollback dello stack; pertanto il compilatore deve inserire, per ogni istruzione nel try...catch che possa sollevare eccezioni anche il codice per verificare se e' stata sollevata un'eccezione ed il relativo codice di unroll dello stack.
La cosa e' piuttosto pesante, ma puo' anche essere peggio. Soprattutto se si programma in Visual C++ con una versione di Visual Studio non aggiornata.
Al tempo (per esempio, VS 2003/2005/...) le eccezioni erano codificate mediante SEH!!! In VS2003 non c'era alternativa, mentre la cosa e' stata messa opzionale nelle versioni successive per mantenere la compatibilita' con il codice precedente.
Questo ovviamente ha un grosso impatto, soprattutto sulla correttezza del codice: i crash avrebbero potuto essere benissimo nascosti e tramutati inconsapevolmente in eccezioni, con risultati disastrosi. Infatti MS si e' poi decisa a cambiare a seguito delle lamentele arrivate.
cdimauro
09-03-2013, 05:00
Non so com'è messo .NET in generale, ma in particolare in IronPython (Python per .NET) le eccezioni sono decisamente pesanti.
Mentre in Python sono abbastanza leggere, e quindi si usano alacremente.
sottovento
09-03-2013, 08:14
Non so com'è messo .NET in generale, ma in particolare in IronPython (Python per .NET) le eccezioni sono decisamente pesanti.
Mentre in Python sono abbastanza leggere, e quindi si usano alacremente.
Molto interessante!!! Hai un'idea del motivo che rende le eccezioni di python cosi' leggere?
Immagino che ci sia una buona ottimizzazione nel caso le eccezioni siano sollevate e intercettate nella stessa funzione. Negli altri casi non ho proprio idea. Hai qualche info? (spero non un link con una spataffiata in inglese, preferisco una cosa semplificata - anche non completamente corretta, purche' renda l'idea)
cdimauro
09-03-2013, 11:01
Non è veloce di per sé, ma rispetto ad IronPython ci sono differenze abissali (mi pare di un paio di ordini di grandezza).
Informazioni non ne ho. Ho studiato il codice di CPython per quanto riguarda l'implementazione degli opcode che utilizza per inizializzare e finalizzare i blocchi di try/except/finally, e viene eseguito poco codice.
Il setup, ad esempio, richiede poche istruzioni. Molte meno rispetto a un'operazione aritmetica, per fare un esempio.
La finalizzazione è anch'essa molto semplice, e richiede generalmente poche istruzioni.
Soltanto il costrutto with è un po' più complesso, perché lì entra in gioco tutto un discorso sui contesti.
Non è veloce di per sé, ma rispetto ad IronPython ci sono differenze abissali (mi pare di un paio di ordini di grandezza).
Informazioni non ne ho. Ho studiato il codice di CPython per quanto riguarda l'implementazione degli opcode che utilizza per inizializzare e finalizzare i blocchi di try/except/finally, e viene eseguito poco codice.
Il setup, ad esempio, richiede poche istruzioni. Molte meno rispetto a un'operazione aritmetica, per fare un esempio.
La finalizzazione è anch'essa molto semplice, e richiede generalmente poche istruzioni.
Soltanto il costrutto with è un po' più complesso, perché lì entra in gioco tutto un discorso sui contesti.
quel finally ha lo scopo di liberare la memoria allocata da un oggetto nel caso venga sollevata una eccezione?
cdimauro
09-03-2013, 12:05
In alcuni casi sì. Ad esempio se l'eccezione provoca l'uscita da una o più funzioni/metodi, viene ripulito il loro stack di variabili, e dunque si perde molto più tempo rispetto a un finally (o except) eseguito in un pezzo di codice "semplice" (che non fa chiamate, o che al limite, pur facendole, le funzioni/metodi chiamati non sollevano eccezioni intercettate da quel try).
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.