Tại sao hàm sau nhanh hơn 10% mặc dù nó phải tạo các biến nhiều lần?

var toSizeString = (function() {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

  return function(size) {
    var gbSize = size / GB,
        gbMod  = size % GB,
        mbSize = gbMod / MB,
        mbMod  = gbMod % MB,
        kbSize = mbMod / KB;

    if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
    } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
    } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
    } else {
      return size + 'B';
    }
  };
})();

Và hàm nhanh hơn: (lưu ý rằng nó phải luôn luôn tính toán các biến giống nhau kb / mb / gb nhiều lần). Nó đạt được hiệu suất ở đâu?

function toSizeString (size) {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

 var gbSize = size / GB,
     gbMod  = size % GB,
     mbSize = gbMod / MB,
     mbMod  = gbMod % MB,
     kbSize = mbMod / KB;

 if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
 } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
 } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
 } else {
      return size + 'B';
 }
};

Tất cả các công cụ JavaScript hiện đại đều thực hiện việc biên dịch đúng lúc. Bạn không thể đưa ra bất kỳ giả định nào về những gì nó "phải tạo ra nhiều lần." Loại tính toán này tương đối dễ dàng để tối ưu hóa, trong cả hai trường hợp.

Mặt khác, việc đóng các biến không đổi không phải là trường hợp điển hình mà bạn sẽ nhắm mục tiêu biên dịch JIT. Bạn thường tạo một bao đóng khi bạn muốn có thể thay đổi các biến đó trên các lệnh khác nhau. Bạn cũng đang tạo một bổ sung con trỏ bổ sung để truy cập các biến đó, như sự khác biệt giữa truy cập một biến thành viên và int cục bộ trong OOP.

Loại tình huống này là lý do tại sao mọi người ném ra dòng "tối ưu hóa sớm". Việc tối ưu hóa dễ dàng đã được thực hiện bởi trình biên dịch.

Biến có giá rẻ. Bối cảnh thực hiện và chuỗi phạm vi là đắt tiền.

Có nhiều câu trả lời khác nhau về cơ bản là "vì đóng cửa" và về cơ bản là đúng, nhưng vấn đề không phải là cụ thể với việc đóng cửa, thực tế là bạn có một hàm tham chiếu các biến trong một phạm vi khác. Bạn sẽ phải cùng một vấn đề nếu đây là những biến toàn cục trên windowđối tượng, như trái ngược với các biến cục bộ bên trong IIFE. Hãy thử nó và xem.

Vì vậy, trong chức năng đầu tiên của bạn, khi động cơ nhìn thấy tuyên bố này:

var gbSize = size / GB;

Nó phải thực hiện các bước sau:

1. Tìm kiếm một biến sizetrong phạm vi hiện tại. (Tìm thấy rồi.)
2. Tìm kiếm một biến GBtrong phạm vi hiện tại. (Không tìm thấy.)
3. Tìm kiếm một biến GBtrong phạm vi cha. (Tìm thấy rồi.)
4. Làm phép tính và gán cho gbSize.

Bước 3 đắt hơn đáng kể so với việc chỉ phân bổ một biến. Hơn nữa, bạn làm điều này năm lần , bao gồm hai lần cho cả hai GBvà MB. Tôi nghi ngờ rằng nếu bạn đặt bí danh cho chúng ở đầu hàm (ví dụ var gb = GB) và tham chiếu bí danh thay vào đó, nó thực sự sẽ tạo ra một tốc độ nhỏ, mặc dù cũng có thể một số công cụ JS đã thực hiện tối ưu hóa này. Và tất nhiên, cách hiệu quả nhất để tăng tốc độ thực thi chỉ đơn giản là không đi qua chuỗi phạm vi.

Hãy nhớ rằng JavaScript không giống như một ngôn ngữ được biên dịch, nhập tĩnh, trong đó trình biên dịch giải quyết các địa chỉ biến này tại thời gian biên dịch. Công cụ JS phải giải quyết chúng theo tên và các lần tra cứu này xảy ra trong thời gian chạy, mọi lúc. Vì vậy, bạn muốn tránh chúng khi có thể.

Chuyển nhượng biến cực kỳ rẻ trong JavaScript. Nó thực sự có thể là hoạt động rẻ nhất, mặc dù tôi không có gì để sao lưu tuyên bố đó. Tuy nhiên, thật an toàn khi nói rằng hầu như không bao giờ nên cố gắng tránh tạo biến; hầu như bất kỳ tối ưu hóa nào bạn cố gắng thực hiện trong lĩnh vực đó thực sự sẽ kết thúc làm cho mọi thứ trở nên tồi tệ hơn, hiệu quả hơn.

Một ví dụ liên quan đến việc đóng cửa, cái kia thì không. Việc thực hiện đóng là khá khó khăn, vì đóng trên các biến không hoạt động như các biến thông thường. Điều này rõ ràng hơn trong một ngôn ngữ cấp thấp như C, nhưng tôi sẽ sử dụng JavaScript để minh họa điều này.

Một bao đóng không chỉ bao gồm một hàm, mà còn bao gồm tất cả các biến mà nó đóng. Khi chúng ta muốn gọi hàm đó, chúng ta cũng cần cung cấp tất cả các biến đóng. Chúng ta có thể mô hình hóa một bao đóng bởi một hàm nhận một đối tượng là đối số đầu tiên đại diện cho các biến đóng này:

function add(vars, y) {
  vars.x += y;
}

function getSum(vars) {
  return vars.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(adder, 2);
console.log(adder.getSum(adder));  //=> 42

Lưu ý quy ước gọi khó xử closure.apply(closure, ...realArgs)này yêu cầu

Hỗ trợ đối tượng dựng sẵn của JavaScript cho phép bỏ qua varsđối số rõ ràng và thisthay vào đó cho phép chúng tôi sử dụng :

function add(y) {
  this.x += y;
}

function getSum() {
  return this.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

Những ví dụ này tương đương với mã này thực sự sử dụng các bao đóng:

function makeAdder(x) {
  return {
    add: function (y) { x += y },
    getSum: function () { return x },
  };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

Trong ví dụ cuối cùng này, đối tượng chỉ được sử dụng để nhóm hai hàm được trả về; các thisràng buộc là không liên quan. Tất cả các chi tiết về việc đóng cửa có thể - chuyển dữ liệu ẩn sang hàm thực tế, thay đổi tất cả các truy cập thành biến đóng để tra cứu trong dữ liệu ẩn đó - được ngôn ngữ quan tâm.

Nhưng việc đóng các cuộc gọi liên quan đến chi phí truyền dữ liệu bổ sung đó và việc đóng cửa liên quan đến chi phí tìm kiếm trong dữ liệu bổ sung đó - trở nên tồi tệ hơn bởi địa phương bộ đệm xấu và thường là một con trỏ khi so sánh với các biến thông thường - vì vậy không có gì đáng ngạc nhiên một giải pháp không dựa vào việc đóng cửa thực hiện tốt hơn. Đặc biệt là tất cả mọi thứ mà việc đóng cửa của bạn giúp bạn thực hiện là một vài thao tác số học cực kỳ rẻ, thậm chí có thể được gấp lại liên tục trong quá trình phân tích cú pháp.