เหตุใดฟังก์ชันหลังจึงเร็วกว่า 10% ถึงแม้ว่ามันจะต้องสร้างตัวแปรซ้ำแล้วซ้ำอีก?

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';
    }
  };
})();

และฟังก์ชั่นที่เร็วขึ้น: (โปรดทราบว่ามันจะต้องคำนวณตัวแปร kb / mb / gb เดียวกันซ้ำแล้วซ้ำอีกเสมอ) ประสิทธิภาพเพิ่มขึ้นที่ไหน?

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';
 }
};

เอ็นจิ้น JavaScript สมัยใหม่ทั้งหมดทำการรวบรวมแบบทันเวลา คุณไม่สามารถทำการสันนิษฐานเกี่ยวกับสิ่งที่มัน "ต้องสร้างซ้ำแล้วซ้ำอีก" การคำนวณแบบนั้นค่อนข้างง่ายในการปรับให้เหมาะสมไม่ว่าในกรณีใด

ในทางกลับกันการปิดทับตัวแปรคงไม่ใช่กรณีทั่วไปที่คุณต้องการกำหนดเป้าหมายการรวบรวม JIT โดยทั่วไปคุณจะสร้างการปิดเมื่อคุณต้องการที่จะสามารถเปลี่ยนแปลงตัวแปรเหล่านั้นในการร้องขอที่แตกต่างกัน นอกจากนี้คุณยังสร้างตัวชี้ความสนใจเพิ่มเติมเพื่อเข้าถึงตัวแปรเหล่านั้นเช่นความแตกต่างระหว่างการเข้าถึงตัวแปรสมาชิกและ Local int ใน OOP

สถานการณ์เช่นนี้เป็นสาเหตุที่ทำให้ผู้คนออกจากสาย "การปรับให้เหมาะสมก่อนวัย" คอมไพเลอร์ได้ทำการปรับให้เหมาะสมแล้ว

ตัวแปรมีราคาถูก บริบทการดำเนินการและขอบเขตของขอบเขตมีราคาแพง

มีคำตอบต่าง ๆ ที่สำคัญโดยทั่วไปแล้วลดลงเหลือ "เพราะการปิด" และคำตอบนั้นเป็นความจริง แต่ปัญหานั้นไม่ได้เกิดขึ้นเฉพาะกับการปิดมันเป็นความจริงที่ว่าคุณมีฟังก์ชั่นอ้างอิงตัวแปรในขอบเขตที่แตกต่างกัน คุณจะมีปัญหาเดียวกันถ้าสิ่งเหล่านี้เป็นตัวแปรทั่วโลกบนwindowวัตถุซึ่งตรงข้ามกับตัวแปรท้องถิ่นภายใน IIFE ลองและดู

ดังนั้นในฟังก์ชั่นแรกของคุณเมื่อเอ็นจิ้นเห็นข้อความนี้:

var gbSize = size / GB;

จะต้องทำตามขั้นตอนต่อไปนี้:

1. ค้นหาตัวแปรsizeในขอบเขตปัจจุบัน (พบมัน)
2. ค้นหาตัวแปรGBในขอบเขตปัจจุบัน (ไม่พบ.)
3. ค้นหาตัวแปรGBในขอบเขตพาเรนต์ (พบมัน)
4. gbSizeทำคำนวณและกำหนดที่จะ

ขั้นตอนที่ 3 มีราคาแพงกว่าการจัดสรรตัวแปร นอกจากนี้คุณทำเช่นนี้ห้าครั้งรวมทั้งครั้งที่สองสำหรับทั้งสองและGB MBฉันสงสัยว่าถ้าคุณใช้นามแฝงเหล่านี้ที่จุดเริ่มต้นของฟังก์ชั่น (เช่นvar gb = GB) และอ้างอิงนามแฝงแทนจริง ๆ แล้วมันจะเร่งความเร็วขนาดเล็กถึงแม้ว่ามันอาจเป็นไปได้ว่าเอ็นจิน JS บางตัวทำการเพิ่มประสิทธิภาพนี้แล้ว และแน่นอนว่าวิธีที่มีประสิทธิภาพมากที่สุดในการเพิ่มความเร็วในการดำเนินการก็คือไม่ต้องข้ามห่วงโซ่ขอบเขตเลย

โปรดทราบว่า JavaScript ไม่เหมือนกับภาษาที่รวบรวมและพิมพ์แบบสแตติกซึ่งคอมไพเลอร์จะแก้ไขตัวแปรที่อยู่เหล่านี้ในเวลารวบรวม เอ็นจิน JS ต้องแก้ไขตามชื่อและการค้นหาเหล่านี้เกิดขึ้นที่รันไทม์ทุกครั้ง ดังนั้นคุณต้องการหลีกเลี่ยงพวกเขาเมื่อเป็นไปได้

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

ตัวอย่างหนึ่งเกี่ยวข้องกับการปิดตัวอื่นไม่ได้ การนำการปิดมาใช้นั้นค่อนข้างยุ่งยากเนื่องจากการปิดทับตัวแปรไม่ทำงานเหมือนตัวแปรปกติ สิ่งนี้ชัดเจนมากขึ้นในภาษาระดับต่ำเช่น C แต่ฉันจะใช้ JavaScript เพื่ออธิบายสิ่งนี้

การปิดไม่เพียง แต่ประกอบด้วยฟังก์ชั่นเท่านั้น แต่ยังรวมถึงตัวแปรทั้งหมดที่ปิดไปด้วย เมื่อเราต้องการเรียกใช้ฟังก์ชันนั้นเราจำเป็นต้องจัดเตรียมตัวแปรปิดทั้งหมด เราสามารถสร้างแบบจำลองการปิดโดยฟังก์ชันที่รับวัตถุเป็นอาร์กิวเมนต์แรกที่แสดงถึงการปิดตัวแปรเหล่านี้:

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

หมายเหตุเรียกประชุมที่น่าอึดอัดใจclosure.apply(closure, ...realArgs)นี้ต้อง

การสนับสนุนวัตถุในตัวของ JavaScript ทำให้สามารถละเว้นvarsอาร์กิวเมนต์ที่ชัดเจนและให้เราใช้thisแทน:

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

ตัวอย่างเหล่านี้เทียบเท่ากับรหัสนี้โดยใช้การปิดจริง:

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

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

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