Uno dei motivi "per cui" è che le eccezioni e la gestione delle eccezioni sono assunto ad essere eccezionale; cioè codice che viene eseguito raramente. Ne consegue che il tempo trascorso dal compilatore JIT sull'ottimizzazione dei gestori di eccezioni avrà un piccolo vantaggio per le prestazioni complessive.
L'ottimizzatore del compilatore JIT deve bilanciare i vantaggi in termini di prestazioni delle ottimizzazioni che sono efficaci contro i costi di ottimizzazione. Questi ultimi comprendono:
- il costo del controllo precondizioni complicati per vedere se un'ottimizzazione è possibile,
- il costo di fare l'ottimizzazione effettivo, e
- il costo (a Oracle) di applicazione e il mantenimento di un complesso pezzo di software che fa un'ottimizzazione che è (in condizioni normali/ipotesi) non sarà efficace.
Ci possono essere anche motivi tecnici che inibiscono l'ottimizzazione dei gestori di eccezioni. Ad esempio, potrebbe non essere facile (o anche possibile) per l'ottimizzatore capire da dove proviene il flusso di controllo ". Quindi, l'ottimizzazione che si basa sul sapere che (ad esempio la memorizzazione nella cache di materiale nei registri, il sollevamento di sottoespressioni comuni, ...) non può essere eseguita.
fonte
2012-07-19 11:49:45
[Questa domanda] (http://stackoverflow.com/questions/299068/how-slow-are-java-exceptions) può essere utile. – Leri