Cuối cùng có đắt không

Trong trường hợp mã mà bạn phải thực hiện dọn dẹp tài nguyên trước khi thoát khỏi hàm, có sự khác biệt lớn về hiệu năng giữa 2 cách thực hiện này không.

1. Làm sạch tài nguyên trước mỗi tuyên bố hoàn trả

   void func()
   {
       login();
   
       bool ret = dosomething();
       if(ret == false)
       {
           logout();
           return;
       }
   
       ret = dosomethingelse();
       if(ret == false)
       {
           logout();
           return;
       }
   
       dootherstuff();
   
       logout();
   }

2. Làm sạch tài nguyên trong một khối cuối cùng

   void func()
   {
       login();
   
       try
       {
           bool ret = dosomething();
           if(ret == false)
               return;
   
           ret = dosomethingelse();
           if(ret == false)
               return;
   
           dootherstuff();
   
       }
       finally
       {
           logout();
       }
   }

Tôi đã thực hiện một số thử nghiệm cơ bản trong các chương trình mẫu và dường như không có nhiều sự khác biệt. Tôi rất thích finallycách làm này - nhưng tôi đã tự hỏi liệu nó sẽ gây ra bất kỳ hiệu suất nào trong một dự án lớn.

Như đã chỉ ra trong các trường hợp ngoại lệ Java chậm như thế nào? người ta có thể thấy rằng sự chậm chạp try {} catch {}nằm trong chính sự xúi giục của ngoại lệ.

Tạo một ngoại lệ sẽ tìm nạp toàn bộ ngăn xếp cuộc gọi từ thời gian chạy và đây là nơi chi phí. Nếu bạn không tạo ra một ngoại lệ, điều này chỉ tăng rất ít thời gian.

Trong ví dụ được đưa ra trong câu hỏi này, không có bất kỳ trường hợp ngoại lệ nào, người ta sẽ không mong đợi bất kỳ sự chậm lại nào khi tạo ra chúng - chúng không được tạo ra. Thay vào đó, những gì ở đây là try {} finally {}để xử lý việc phân bổ tài nguyên trong khối cuối cùng.

Vì vậy, để trả lời câu hỏi, không, không có chi phí thời gian thực trong try {} finally {}cấu trúc không sử dụng ngoại lệ (không phải là chưa từng thấy, như đã thấy). Có gì là có thể đắt tiền là thời gian bảo trì khi người ta đọc mã và thấy phong cách mã không điển hình này và các coder có để có được tâm trí của họ xung quanh rằng cái gì khác xảy ra trong phương pháp này sau khi returntrước khi trở về cuộc gọi trước đó.

Như đã đề cập, bảo trì là một đối số cho cả hai cách để làm điều này. Đối với hồ sơ, sau khi xem xét, sở thích của tôi sẽ là phương pháp cuối cùng.

Xem xét thời gian duy trì dạy cho ai đó một cấu trúc ngôn ngữ mới. Nhìn thấy try {} finally {}không phải là thứ mà người ta thường thấy trong mã Java và do đó có thể gây nhầm lẫn cho mọi người. Có một mức độ thời gian bảo trì để tìm hiểu các cấu trúc nâng cao hơn một chút trong Java so với những gì mọi người quen thuộc nhìn thấy.

Các finally {}khối luôn luôn chạy. Và đây là lý do tại sao bạn nên sử dụng nó. Cũng xem xét thời gian duy trì gỡ lỗi của phương pháp không cuối cùng khi ai đó quên bao gồm đăng xuất vào thời điểm thích hợp hoặc gọi nó vào thời điểm không thích hợp hoặc quên trả lại / thoát sau khi gọi nó để được gọi hai lần. Có rất nhiều lỗi có thể xảy ra với điều này mà việc sử dụng try {} finally {}khiến không thể có.

Khi cân nhắc hai chi phí này, sẽ tốn kém trong thời gian bảo trì không sử dụng try {} finally {}phương pháp này. Mặc dù mọi người có thể tinh ranh hơn về việc có bao nhiêu phần nghìn giây hoặc hướng dẫn jvm bổ sung mà try {} finally {}khối được so sánh với phiên bản khác, người ta cũng phải xem xét số giờ dành cho việc gỡ lỗi theo cách giải quyết tài nguyên ít hơn lý tưởng.

Viết mã có thể duy trì trước, và tốt nhất là theo cách sẽ ngăn các lỗi được viết sau đó.

/programming/299068/how-slow-are-java-exceptions

Câu trả lời được chấp nhận cho câu hỏi này cho thấy việc gói một lệnh gọi hàm trong khối thử bắt có chi phí ít hơn 5% so với cuộc gọi hàm trần. Trên thực tế, việc ném và bắt ngoại lệ đã khiến cho bộ thực thi tăng vọt lên hơn 66 lần so với lệnh gọi hàm trần. Vì vậy, nếu bạn mong đợi thiết kế ngoại lệ được ném thường xuyên thì tôi sẽ cố gắng tránh nó (trong mã quan trọng hiệu năng được định hình đúng), tuy nhiên nếu tình huống đặc biệt là hiếm thì đó không phải là vấn đề lớn.

Thay vì tối ưu hóa - hãy nghĩ về những gì mã của bạn đang làm.

Thêm khối cuối cùng là một triển khai khác - điều đó có nghĩa là bạn sẽ đăng xuất trên mọi ngoại lệ.

Cụ thể - nếu đăng nhập ném một ngoại lệ, hành vi trong chức năng thứ hai của bạn sẽ khác với lần đầu tiên.

Nếu đăng nhập và đăng xuất không thực sự là một phần của hành vi chức năng thì tôi sẽ đề xuất rằng phương thức này nên thực hiện một điều và một điều tốt:

    void func()
    {
            bool ret = dosomething();
            if(ret == false)
                return;

            ret = dosomethingelse();
            if(ret == false)
                return;

            dootherstuff();

    }

và phải ở trong một chức năng đã được gói gọn trong ngữ cảnh quản lý đăng nhập / đăng xuất vì chúng có vẻ khác về cơ bản với những gì mã chính của bạn đang làm.

Bài đăng của bạn được gắn thẻ là Java mà tôi không quen thuộc lắm nhưng trong .net tôi sẽ sử dụng một khối sử dụng cho việc này:

I E:

    using(var loginContext = CreateLoginContext()) 
    {
            // Do all your stuff
    }

Và bối cảnh đăng nhập có một phương thức Vứt bỏ sẽ đăng xuất và dọn sạch các tài nguyên.

Chỉnh sửa: Tôi đã không thực sự trả lời câu hỏi!

Tôi không có bằng chứng có thể đo lường được nhưng tôi không hy vọng nó sẽ đắt hơn hoặc chắc chắn không đủ đắt để nó xứng đáng được tối ưu hóa sớm.

Tôi sẽ để lại phần còn lại của câu trả lời vì mặc dù không trả lời câu hỏi, tôi nghĩ nó hữu ích cho OP.

Giả định: Bạn đang phát triển mã C #.

Câu trả lời nhanh là không có hiệu suất đáng kể nào khi sử dụng các khối try / cuối cùng. Có một hiệu suất hit khi bạn ném và bắt ngoại lệ.

Câu trả lời dài hơn là để xem cho chính mình. Nếu bạn nhìn vào mã CIL cơ bản được tạo ( ví dụ: bộ phản xạ cổng đỏ thì bạn có thể thấy các hướng dẫn CIL cơ bản được tạo và xem tác động theo cách đó.

Như những người khác đã lưu ý, mã Ticky sẽ có kết quả khác nhau, nếu dosomethingelsehoặc dootherstuffném ngoại lệ.

Và vâng, bất kỳ cuộc gọi chức năng nào cũng có thể đưa ra một ngoại lệ, ít nhất là a StackOVerflowError! Mặc dù hiếm khi có thể xử lý chúng một cách chính xác (vì bất kỳ chức năng dọn dẹp nào được gọi là có thể sẽ có cùng một vấn đề, trong một số trường hợp (chẳng hạn như thực hiện các khóa chẳng hạn), điều quan trọng là phải xử lý chính xác ...