Cloudflare, Mozilla ແລະ Facebook ພັດທະນາ BinaryAST ເພື່ອເລັ່ງການໂຫຼດ JavaScript

ວິສະວະກອນຈາກ Cloudflare, Mozilla, Facebook ແລະ Bloomberg ສະ ເໜີ ຮູບ​ແບບ​ໃຫມ່​ binaryAST ເພື່ອເລັ່ງການຈັດສົ່ງແລະການປະມວນຜົນລະຫັດ JavaScript ເມື່ອເປີດເວັບໄຊທ໌ໃນ browser. BinaryAST ຍ້າຍໄລຍະການແຍກໄປຫາຝ່າຍເຊີບເວີ ແລະສະໜອງຕົ້ນໄມ້ syntax abstract ທີ່ສ້າງຂຶ້ນແລ້ວ (AST). ເມື່ອໄດ້ຮັບ BinaryAST, ຕົວທ່ອງເວັບສາມາດດໍາເນີນຂັ້ນຕອນການລວບລວມໄດ້ທັນທີ, ໂດຍຂ້າມການແຍກວິເຄາະລະຫັດແຫຼ່ງ JavaScript.

ສຳ ລັບການທົດສອບ ກະກຽມ ການປະຕິບັດການອ້າງອິງທີ່ສະຫນອງພາຍໃຕ້ໃບອະນຸຍາດ MIT. ອົງປະກອບຂອງ Node.js ຖືກນໍາໃຊ້ສໍາລັບການວິເຄາະ, ແລະລະຫັດສໍາລັບການເພີ່ມປະສິດທິພາບແລະການຜະລິດ AST ແມ່ນຂຽນໃນ Rust. ສະຫນັບສະຫນູນດ້ານຕົວທ່ອງເວັບ
BinaryAST ມີຢູ່ແລ້ວໃນ ການຊຸມນຸມໃນຕອນກາງຄືນ Firefox. ຕົວເຂົ້າລະຫັດໃນ BinaryAST ສາມາດນໍາໃຊ້ໄດ້ທັງໃນລະດັບເຄື່ອງມືຂອງສະຖານທີ່ສິ້ນສຸດແລະສໍາລັບສະຄິບການຫຸ້ມຫໍ່ຂອງສະຖານທີ່ພາຍນອກຢູ່ດ້ານຂ້າງຂອງເຄືອຂ່າຍການຈັດສົ່ງຕົວແທນຫຼືເນື້ອຫາ. ໃນປັດຈຸບັນ, ຂະບວນການມາດຕະຖານຂອງ BinaryAST ໂດຍຄະນະປະຕິບັດງານໄດ້ເລີ່ມຂຶ້ນແລ້ວ ECMA TC39, ຫຼັງຈາກນັ້ນຮູບແບບດັ່ງກ່າວຈະສາມາດຢູ່ຮ່ວມກັນກັບວິທີການບີບອັດເນື້ອຫາທີ່ມີຢູ່, ເຊັ່ນ: gzip ແລະ brotli.

ເມື່ອປະມວນຜົນ JavaScript, ໄລຍະເວລາທີ່ສໍາຄັນແມ່ນໃຊ້ເວລາໃນໄລຍະການໂຫຼດແລະການວິເຄາະລະຫັດ. ພິຈາລະນາວ່າປະລິມານຂອງ JavaScript ທີ່ດາວໂຫລດຢູ່ໃນເວັບໄຊທ໌ທີ່ນິຍົມຫຼາຍແມ່ນຢູ່ໃກ້ກັບ 10 MB (ຕົວຢ່າງເຊັ່ນ: ສໍາລັບ LinkedIn - 7.2 MB, Facebook - 7.1 MB, Gmail - 3.9 MB), ການປະມວນຜົນເບື້ອງຕົ້ນຂອງ JavaScript ແນະນໍາການຊັກຊ້າທີ່ສໍາຄັນ. ຂັ້ນຕອນການວິເຄາະໃນດ້ານຂອງຕົວທ່ອງເວັບແມ່ນຍັງຊ້າລົງເນື່ອງຈາກບໍ່ສາມາດສ້າງ AST ຢ່າງເຕັມທີ່ໃນການບິນຍ້ອນວ່າລະຫັດຖືກໂຫລດ (ຕົວທ່ອງເວັບຕ້ອງລໍຖ້າການບລັອກລະຫັດເພື່ອສໍາເລັດການໂຫຼດ, ເຊັ່ນ: ສິ້ນສຸດຂອງຫນ້າທີ່, ເພື່ອໃຫ້ໄດ້ຮັບ. ຂໍ້​ມູນ​ທີ່​ຂາດ​ໄປ​ເພື່ອ​ວິ​ເຄາະ​ອົງ​ປະ​ກອບ​ໃນ​ປະ​ຈຸ​ບັນ​)​.

ພວກເຂົາກໍາລັງພະຍາຍາມແກ້ໄຂບັນຫາບາງສ່ວນໂດຍການແຈກຢາຍລະຫັດໃນຮູບແບບທີ່ນ້ອຍລົງແລະຖືກບີບອັດ, ເຊັ່ນດຽວກັນກັບການເກັບຮັກສາ bytecode ທີ່ສ້າງຂຶ້ນໂດຍຕົວທ່ອງເວັບ. ຢູ່ໃນສະຖານທີ່ທີ່ທັນສະໄຫມ, ລະຫັດໄດ້ຖືກປັບປຸງເລື້ອຍໆ, ດັ່ງນັ້ນການເກັບຮັກສາໄວ້ພຽງແຕ່ບາງສ່ວນແກ້ໄຂບັນຫາ. WebAssembly ອາດຈະເປັນການແກ້ໄຂ, ແຕ່ມັນຮຽກຮ້ອງໃຫ້ມີການພິມລະຫັດທີ່ຊັດເຈນແລະບໍ່ເຫມາະສົມກັບການເລັ່ງການປຸງແຕ່ງລະຫັດ JavaScript ທີ່ມີຢູ່.

ທາງເລືອກອື່ນແມ່ນການຈັດສົ່ງ bytecode ທີ່ພ້ອມທີ່ຈະເຮັດແລ້ວແທນທີ່ຈະເປັນ scripts JavaScript, ແຕ່ຜູ້ພັດທະນາເຄື່ອງຈັກຂອງຕົວທ່ອງເວັບແມ່ນຕໍ່ຕ້ານມັນເພາະວ່າ bytecode ພາກສ່ວນທີສາມມີຄວາມຫຍຸ້ງຍາກໃນການກວດສອບ, ການປຸງແຕ່ງໂດຍກົງຂອງມັນສາມາດນໍາໄປສູ່ການຈັດແບ່ງເວັບ, ຄວາມສ່ຽງດ້ານຄວາມປອດໄພເພີ່ມເຕີມເກີດຂື້ນ, ແລະການພັດທະນາຂອງ. ຕ້ອງມີຮູບແບບ bytecode ທົ່ວໄປ.

BinaryAST ອະນຸຍາດໃຫ້ທ່ານເຂົ້າກັບການພັດທະນາລະຫັດໃນປະຈຸບັນຂອງທ່ານແລະຮູບແບບການຈັດສົ່ງໂດຍບໍ່ມີການສ້າງ bytecode ໃຫມ່ຫຼືປ່ຽນພາສາ JavaScript. ຂະຫນາດຂອງຂໍ້ມູນໃນຮູບແບບ BinaryAST ແມ່ນທຽບກັບລະຫັດ JavaScript ທີ່ຖືກບີບອັດຫນ້ອຍລົງ, ແລະຄວາມໄວໃນການປຸງແຕ່ງໂດຍການກໍາຈັດໄລຍະການແຍກຂໍ້ຄວາມຕົ້ນສະບັບເພີ່ມຂຶ້ນຢ່າງເຫັນໄດ້ຊັດ. ນອກຈາກນັ້ນ, ຮູບແບບດັ່ງກ່າວອະນຸຍາດໃຫ້ການລວບລວມກັບ bytecode ຍ້ອນວ່າ BinaryAST ຖືກໂຫລດ, ໂດຍບໍ່ຕ້ອງລໍຖ້າຂໍ້ມູນທັງຫມົດສໍາເລັດ. ນອກຈາກນັ້ນ, parsing ໃນດ້ານເຊີຟເວີຊ່ວຍໃຫ້ທ່ານສາມາດຍົກເວັ້ນຫນ້າທີ່ບໍ່ໄດ້ໃຊ້ແລະລະຫັດທີ່ບໍ່ຈໍາເປັນຈາກການເປັນຕົວແທນຂອງ BinaryAST ທີ່ຖືກສົ່ງຄືນ, ເຊິ່ງ, ເມື່ອ parsing ໃນດ້ານຂອງຕົວທ່ອງເວັບ, ເຮັດໃຫ້ເສຍເວລາທັງ parsing ແລະສົ່ງການຈະລາຈອນທີ່ບໍ່ຈໍາເປັນ.

ຄຸນນະສົມບັດຂອງ BinaryAST ຍັງເປັນຄວາມສາມາດໃນການຟື້ນຟູ JavaScript ທີ່ສາມາດອ່ານໄດ້ທີ່ບໍ່ຄືກັນກັບສະບັບຕົ້ນສະບັບ, ແຕ່ມີຄວາມສົມດຸນທາງຄວາມຫມາຍແລະປະກອບມີຊື່ຂອງຕົວແປແລະຫນ້າທີ່ດຽວກັນ (BinaryAST ບັນທຶກຊື່, ແຕ່ບໍ່ໄດ້ບັນທຶກຂໍ້ມູນກ່ຽວກັບຕໍາແຫນ່ງໃນ. ລະຫັດ, ຮູບແບບແລະຄໍາເຫັນ). ອີກດ້ານຫນຶ່ງຂອງຫຼຽນແມ່ນການປະກົດຕົວຂອງ vectors ການໂຈມຕີໃຫມ່, ແຕ່ອີງຕາມນັກພັດທະນາ, ພວກມັນມີຂະຫນາດນ້ອຍກວ່າແລະສາມາດຄວບຄຸມໄດ້ຫຼາຍກ່ວາໃນເວລາທີ່ໃຊ້ທາງເລືອກເຊັ່ນການແຈກຢາຍ bytecode.

ການທົດສອບລະຫັດ facebook.com ສະແດງໃຫ້ເຫັນວ່າການແຍກ JavaScript ໃຊ້ຊັບພະຍາກອນ CPU 10-15% ແລະການວິເຄາະໃຊ້ເວລາຫຼາຍກວ່າການສ້າງ bytecode ແລະການສ້າງລະຫັດເບື້ອງຕົ້ນສໍາລັບ JIT. ໃນເຄື່ອງຈັກ SpiderMonkey, ເວລາທີ່ຈະສ້າງ AST ຢ່າງສົມບູນໃຊ້ເວລາ 500-800 ms, ແລະການນໍາໃຊ້ BinaryAST ໄດ້ຫຼຸດລົງຕົວເລກນີ້ໂດຍ 70-90%.
ໂດຍທົ່ວໄປ, ສໍາລັບ fireworks ເວັບໄຊຕ໌ສ່ວນໃຫຍ່, ເມື່ອນໍາໃຊ້ BinaryAST, ເວລາການວິເຄາະ JavaScript ຫຼຸດລົງ 3-10% ໃນໂຫມດໂດຍບໍ່ມີການເພີ່ມປະສິດທິພາບແລະ 90-97% ເມື່ອໂຫມດການລະເວັ້ນຫນ້າທີ່ບໍ່ໄດ້ໃຊ້ຖືກເປີດໃຊ້.
ເມື່ອແລ່ນຊຸດທົດສອບ 1.2 MB JavaScript, ການນໍາໃຊ້ BinaryAST ໄດ້ອະນຸຍາດໃຫ້ເວລາເລີ່ມຕົ້ນທີ່ຈະເລັ່ງຈາກ 338 ເປັນ 314 ms ໃນລະບົບ desktop (Intel i7) ແລະຈາກ 2019 ຫາ 1455 ms ໃນອຸປະກອນມືຖື (HTC One M8).

ແຫຼ່ງຂໍ້ມູນ: opennet.ru