การใช้บล็อกแบบลองดักจับมีราคาแพงแม้ว่าจะไม่มีข้อยกเว้นเกิดขึ้นหรือไม่

เรารู้ว่ามันแพงในการจับยกเว้น แต่มันก็มีราคาแพงที่จะใช้บล็อก try-catch ใน Java แม้ว่าข้อยกเว้นจะไม่ถูกโยนทิ้ง?

ฉันพบคำถาม / คำตอบ Stack Overflow เหตุใดการลองบล็อกจึงมีราคาแพง แต่มันเป็น.NET

tryแทบไม่มีค่าใช้จ่ายเลย แทนการทำงานของการตั้งค่าtryat runtime ข้อมูลเมตาของรหัสถูกจัดโครงสร้างในเวลาคอมไพล์เช่นเมื่อมีการโยนข้อยกเว้นตอนนี้จะเป็นการดำเนินการที่ค่อนข้างแพงในการเดินขึ้นสแต็กและดูว่ามีtryบล็อกใด ๆข้อยกเว้น จากมุมมองของคนธรรมดาก็tryอาจเป็นอิสระ จริงๆแล้วมันเป็นการยกเว้นที่ทำให้คุณต้องเสียค่าใช้จ่าย แต่ถ้าคุณไม่ได้รับการยกเว้นหลายร้อยหรือหลายพันข้อยกเว้นคุณยังคงไม่สังเกตเห็นค่าใช้จ่าย

tryมีค่าใช้จ่ายเล็กน้อยที่เกี่ยวข้อง Java ไม่สามารถทำการเพิ่มประสิทธิภาพบางอย่างในรหัสในtryบล็อกที่มันจะทำอย่างอื่น ตัวอย่างเช่น Java มักจะจัดเรียงคำสั่งในวิธีการเพื่อให้ทำงานได้เร็วขึ้น - แต่ Java ยังต้องการรับประกันว่าหากมีการโยนข้อยกเว้นการดำเนินการของวิธีการจะถูกตรวจสอบราวกับคำสั่งของมันตามที่เขียนไว้ในซอร์สโค้ด ในการสั่งซื้อถึงบางบรรทัด

เพราะในtryบล็อกสามารถโยนข้อยกเว้น (ที่บรรทัดใด ๆ ในบล็อกลอง! ข้อยกเว้นบางอย่างจะถูกโยนแบบอะซิงโครนัสเช่นโดยการเรียกstopใช้เธรด (ซึ่งเลิกใช้แล้ว) และแม้แต่นอกเหนือจากนั้น OutOfMemoryError สามารถถูกจับได้และโค้ดจะยังคงทำงานหลังจากนั้นในวิธีเดียวกันมันเป็นเรื่องยากที่จะให้เหตุผลเกี่ยวกับการปรับให้เหมาะสมที่สามารถทำได้ดังนั้นจึงมีโอกาสน้อยที่จะเกิดขึ้น (ใครบางคนจะต้องเขียนโปรแกรมคอมไพเลอร์เพื่อทำเหตุผลและรับประกันความถูกต้อง ฯลฯ มันจะเป็นความเจ็บปวดครั้งใหญ่สำหรับบางสิ่งบางอย่างที่หมายถึง 'ยอดเยี่ยม') แต่ในทางปฏิบัติคุณจะไม่สังเกตเห็นสิ่งนี้

มาวัดกันใช่ไหม

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    abstract int run(int iterations) throws Throwable;

    private BigDecimal time() {
        try {
            int nextI = 1;
            int i;
            long duration;
            do {
                i = nextI;
                long start = System.nanoTime();
                run(i);
                duration = System.nanoTime() - start;
                nextI = (i << 1) | 1;
            } while (duration < 100000000 && nextI > 0);
            return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    public String toString() {
        return name + "\t" + time() + " ns";
    }

    public static void main(String[] args) throws Exception {
        Benchmark[] benchmarks = {
            new Benchmark("try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        try {
                            x += i;
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                    return x;
                }
            }, new Benchmark("no try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x += i;
                    }
                    return x;
                }
            }
        };
        for (Benchmark bm : benchmarks) {
            System.out.println(bm);
        }
    }
}

ในคอมพิวเตอร์ของฉันสิ่งนี้จะพิมพ์สิ่งที่ชอบ:

try     0.598 ns
no try  0.601 ns

อย่างน้อยในตัวอย่างเล็ก ๆ น้อย ๆ นี้คำสั่งลองไม่มีผลกระทบที่วัดได้ต่อประสิทธิภาพ อย่าลังเลที่จะวัดสิ่งที่ซับซ้อนมากขึ้น

โดยทั่วไปฉันขอแนะนำว่าอย่ากังวลเกี่ยวกับค่าใช้จ่ายของการสร้างภาษาจนกว่าคุณจะมีหลักฐานของปัญหาประสิทธิภาพที่แท้จริงในโค้ดของคุณ หรืออย่างที่ Donald Knuth กล่าวไว้: "การเพิ่มประสิทธิภาพก่อนวัยอันควรเป็นรากฐานของความชั่วทั้งหมด"

try/ catchอาจมีผลกระทบต่อประสิทธิภาพ นี่เป็นเพราะมันป้องกันไม่ให้ JVM ทำการเพิ่มประสิทธิภาพบางอย่าง Joshua Bloch ใน "Effective Java" กล่าวว่า:

•การวางโค้ดในบล็อก try-catch จะยับยั้งการปรับแต่งบางอย่างที่การนำ JVM มาใช้อาจทำได้

ใช่ดังที่คนอื่น ๆ บอกว่าtryบล็อกขัดขวางการเพิ่มประสิทธิภาพบางอย่างของ{}ตัวละครที่อยู่รอบ ๆ โดยเฉพาะอย่างยิ่งเครื่องมือเพิ่มประสิทธิภาพจะต้องสมมติว่ามีข้อยกเว้นเกิดขึ้น ณ จุดใด ๆ ในบล็อกดังนั้นจึงไม่มีความมั่นใจว่าข้อความจะถูกดำเนินการ

ตัวอย่างเช่น:

    try {
        int x = a + b * c * d;
        other stuff;
    }
    catch (something) {
        ....
    }
    int y = a + b * c * d;
    use y somehow;

โดยไม่ต้องtryมีค่าคำนวณเพื่อกำหนดให้xจะถูกบันทึกไว้ว่าเป็น "subexpression ทั่วไป" yและนำกลับมากำหนดให้ แต่เนื่องจากtryไม่มีการรับประกันว่าการแสดงออกครั้งแรกจะได้รับการประเมินดังนั้นการแสดงออกจะต้องคำนวณใหม่ นี่ไม่ใช่เรื่องใหญ่ในรหัส "เส้นตรง" แต่อาจมีความสำคัญในการวนซ้ำ

อย่างไรก็ตามควรสังเกตว่าสิ่งนี้ใช้ได้กับรหัส JITCed เท่านั้น javac ทำการเพิ่มประสิทธิภาพเพียงเล็กน้อยและไม่มีค่าใช้จ่ายใด ๆ กับล่าม bytecode เพื่อเข้า / ออกtryบล็อก (ไม่มีรหัสไบต์สร้างขึ้นเพื่อทำเครื่องหมายขอบเขตบล็อก)

และสำหรับ bestsss:

public class TryFinally {
    public static void main(String[] argv) throws Throwable {
        try {
            throw new Throwable();
        }
        finally {
            System.out.println("Finally!");
        }
    }
}

เอาท์พุท:

C:\JavaTools>java TryFinally
Finally!
Exception in thread "main" java.lang.Throwable
        at TryFinally.main(TryFinally.java:4)

javap เอาท์พุท:

C:\JavaTools>javap -c TryFinally.class
Compiled from "TryFinally.java"
public class TryFinally {
  public TryFinally();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Throwable;
    Code:
       0: new           #2                  // class java/lang/Throwable
       3: dup
       4: invokespecial #3                  // Method java/lang/Throwable."<init>":()V
       7: athrow
       8: astore_1
       9: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      12: ldc           #5                  // String Finally!
      14: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      17: aload_1
      18: athrow
    Exception table:
       from    to  target type
           0     9     8   any
}

ไม่ใช่ "GOTO"

เพื่อทำความเข้าใจว่าเหตุใดการเพิ่มประสิทธิภาพจึงไม่สามารถทำได้จึงเป็นประโยชน์ที่จะเข้าใจกลไกพื้นฐาน ตัวอย่างรวบรัดที่สุดที่ฉันสามารถหาได้นำมาใช้ในมาโคร C ที่: http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

#include <stdio.h>
#include <setjmp.h>
#define TRY do{ jmp_buf ex_buf__; switch( setjmp(ex_buf__) ){ case 0: while(1){
#define CATCH(x) break; case x:
#define FINALLY break; } default:
#define ETRY } }while(0)
#define THROW(x) longjmp(ex_buf__, x)

คอมไพเลอร์มักมีปัญหาในการพิจารณาว่าการกระโดดสามารถแปลเป็น X, Y และ Z ได้หรือไม่ดังนั้นพวกเขาจึงข้ามการเพิ่มประสิทธิภาพที่พวกเขาไม่สามารถรับประกันได้ว่าจะปลอดภัย แต่การใช้งานนั้นค่อนข้างเบา

อีก microbenchmark ( แหล่งที่มา )

ฉันสร้างการทดสอบที่ฉันวัดรุ่นรหัสลองจับและไม่ลองจับตามเปอร์เซ็นต์ข้อยกเว้น 10% เปอร์เซ็นต์หมายความว่า 10% ของกรณีทดสอบมีการหารด้วยศูนย์กรณี ในสถานการณ์หนึ่งจะได้รับการจัดการโดยบล็อก try-catch ในอีกสถานการณ์หนึ่งโดยผู้ดำเนินการตามเงื่อนไข นี่คือตารางผลลัพธ์ของฉัน:

OS: Windows 8 6.2 x64
JVM: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 23.25-b01

ร้อยละ ผลลัพธ์ (ลอง / ถ้า, ns)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

ซึ่งบอกว่าไม่มีความแตกต่างอย่างมีนัยสำคัญระหว่างกรณีใด ๆ เหล่านี้

ฉันพบว่าการจับ NullPointException ค่อนข้างแพง สำหรับการปฏิบัติการ 1.2k เวลานั้นคือ 200ms และ 12ms เมื่อฉันพกมันแบบเดียวกับif(object==null)ที่ฉันได้รับการปรับปรุง