Điểm chuẩn của Java Try/Catch Block

Question

Tôi biết rằng việc đi vào khối catch có một số chi phí quan trọng khi thực hiện một chương trình, tuy nhiên, tôi đã tự hỏi nếu nhập một khối try {} cũng có bất kỳ tác động nào nên tôi bắt đầu tìm kiếm câu trả lời trong google với nhiều ý kiến, nhưng không có điểm chuẩn nào cả. Một số câu trả lời tôi nhận thấy là:

1. Java try/catch performance, is it recommended to keep what is inside the try clause to a minimum?
2. Try Catch Performance Java
3. Java try catch blocks

Tuy nhiên họ đã không trả lời câu hỏi của tôi với những sự kiện, vì vậy tôi quyết định thử nó cho bản thân mình.

Đây là những gì tôi đã làm. Tôi có một tập tin csv với định dạng này:

host;ip;number;date;status;email;uid;name;lastname;promo_code;

nơi tất cả mọi thứ sau khi tình trạng là không bắt buộc và thậm chí sẽ không có tương ứng; , do đó, khi phân tích cú pháp xác thực phải được thực hiện để xem liệu giá trị có ở đó không, đây là nơi vấn đề try/catch xuất hiện trong tâm trí của tôi.

Mã hiện tại mà tôi được thừa hưởng trong công ty của tôi thực hiện điều này:

StringTokenizer st=new StringTokenizer(line,";"); 
String host = st.nextToken(); 
String ip = st.nextToken(); 
String number = st.nextToken(); 
String date = st.nextToken(); 
String status = st.nextToken();        
String email = ""; 
try{ 
    email = st.nextToken(); 
}catch(NoSuchElementException e){ 
    email = ""; 
} 

và nó lặp đi lặp lại những gì nó được thực hiện cho email với uid, tên, lastname và promo_code.

và tôi đã thay đổi tất cả mọi thứ để:

if(st.hasMoreTokens()){ 
    email = st.nextToken(); 
} 

và trong thực tế nó thực hiện nhanh hơn. Khi phân tích cú pháp tệp không có cột tùy chọn. Dưới đây là thời gian trung bình:

--- Trying:122 milliseconds 
--- Checking:33 milliseconds 

tuy nhiên

, đây là những gì nhầm lẫn tôi và lý do tôi đang hỏi: Khi chạy ví dụ với các giá trị cho các cột tùy chọn trong tất cả 8000 dòng CSV, phiên bản if() vẫn hoạt động tốt hơn phiên bản thử/nắm bắt, do đó, câu hỏi của tôi là

Khối thử thực sự không có bất kỳ tác động hiệu suất nào trên mã của tôi không?

Thời gian trung bình cho ví dụ này là:

--- Trying:105 milliseconds 
--- Checking:43 milliseconds 

ai đó có thể giải thích những gì đang xảy ra ở đây?

Cảm ơn rất nhiều

Answer 1

Có, hãy thử (trong Java) không có bất kỳ tác động hiệu suất nào. Trình biên dịch không tạo ra các câu lệnh VM cho khối thử. Nó chỉ đơn giản là ghi lại các bộ đếm chương trình mà giữa đó khối try đang hoạt động và đính kèm thông tin này vào phương thức trong tệp lớp. Sau đó, khi một ngoại lệ được ném, máy ảo sẽ bung ngăn xếp và kiểm tra ở mỗi khung cho dù bộ đếm chương trình trong khung đó nằm trong khối thử có liên quan hay không. Điều này (cùng với việc xây dựng các dấu vết stack) là khá tốn kém, vì vậy đánh bắt là tốn kém. Tuy nhiên, cố gắng là miễn phí :).

Tuy nhiên, thực tiễn không tốt là sử dụng ngoại lệ cho luồng kiểm soát thông thường.

Lý do tại sao mã của bạn hoạt động nhanh hơn có thể là việc đánh bắt cực kỳ tốn kém đến mức tiết kiệm thời gian bằng cách thay thế séc bằng một lần thử đơn giản.

Thử bắt có thể nhanh hơn trong mã nơi bắt được kích hoạt không thường xuyên, ví dụ: nếu bạn thử 10.000 lần nhưng chỉ bắt được một lần, phương pháp thử sẽ nhanh hơn nếu kiểm tra. Tuy nhiên, đây không phải là phong cách tốt và cách của bạn để kiểm tra rõ ràng cho nhiều mã thông báo hơn là được ưu tiên.