Codice nel try meno performante?

[biowep]

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]

Originariamente inviato da biowep

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

[biowep]

Originariamente inviato da The_ouroboros

l'overhead eventuale è nulla rispetto ai vantaggi

Quindi scrivere tutto il programma in un try sarebbe una buona abitudine di programmazione?

[The_ouroboros]

Originariamente inviato da biowep

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]

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/1...y-catch-blocks
Quasi sicuramente ci sono altre risorse in rete e anche meglio approfondite

Qui invece un piccolo bench --> http://stackoverflow.com/questions/1...y-catch-blocks

Ps
comunque secondo me è proprio una pippa mentale pensare all'overhead del try/catch

[The_ouroboros]

ovviamente intendevo usarlo dove serve e non tanto per usarlo.

[clockover]

Originariamente inviato da The_ouroboros

ovviamente intendevo usarlo dove serve e non tanto per usarlo.

infatti oggi non riesco a esprimermi... ho bisogno di dormire

[sottovento]

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]

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]

Originariamente inviato da cdimauro

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]

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.

[misterx]

Originariamente inviato da cdimauro

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]

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).