คอมไพเลอร์ JavaScript ตัวใหม่ที่เรียกว่า Porffor ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนนักพัฒนา หลังจากแสดงให้เห็นถึงการเพิ่มประสิทธิภาพที่น่าประทับใจบน AWS Lambda เครื่องมือทดลองนี้คอมไพล์ JavaScript แบบ ahead-of-time ไปเป็น WebAssembly และ native binaries โดยอ้างว่าสามารถกำจัดความล่าช้าในการเริ่มต้นแบบ cold start ที่เป็นปัญหาใหญ่ของแอปพลิเคชัน serverless
โครงการนี้ได้รับความสนใจจากการสร้าง binaries ขนาดเล็กต่ำกว่า 1MB ที่สามารถเริ่มต้นได้ในระดับมิลลิวินาที เมื่อเทียบกับ Node.js runtime แบบดั้งเดิมที่อาจใช้เวลาหลายร้อยมิลลิวินาทีในการเริ่มต้น ในการทดสอบประสิทธิภาพบน Lambda, Porffor แสดงให้เห็นการเริ่มต้นแบบ cold start ที่เร็วกว่า Node.js 12 เท่า และเร็วกว่า LLRT runtime ของ Amazon เอง 4 เท่า
การเปรียบเทียบประสิทธิภาพ (เวลาเริ่มต้นแบบเย็น)
- Porffor: ~25ms (P50), ~50ms (P99)
- LLRT: ~100ms (P50), ~200ms (P99)
- Node.js: ~150ms (P50), ~300ms (P99)
การเปรียบเทียบขนาดไฟล์ Binary
- Porffor: 16KB
- Bun compiled: 97MB
- Deno compiled: 82MB
การทดสอบความเร็วในการประมวลผล
- Porffor: 631.4 µs ± 128.5 µs
- Bun: 15.9 ms ± 1.2 ms (ช้ากว่า 25 เท่า)
- Deno: 37.4 ms ± 1.7 ms (ช้ากว่า 59 เท่า)
 |
|---|
| สำรวจว่า Porffor ช่วยเพิ่มประสิทธิภาพอย่างไรด้วยการขจัด JavaScript cold starts บน AWS Lambda |
การอ้างสิทธิ์ด้านประสิทธิภาพเผชิญความสงสัย
แม้ว่าตัวเลขดิบจะดูน่าประทับใจ แต่สมาชิกในชุมชนกำลังตั้งข้อกังวลเกี่ยวกับความถูกต้องของการเปรียบเทียบเหล่านี้ นักพัฒนาหลายคนชี้ให้เห็นว่า Porffor ปัจจุบันรองรับเพียง 60% ของฟีเจอร์ JavaScript และขาดความสามารถที่จำเป็นอย่างการดำเนินการ I/O และความเข้ากันได้กับ Node.js นักวิจารณ์โต้แย้งว่าสิ่งนี้ทำให้การเปรียบเทียบประสิทธิภาพเป็นเรื่องที่ทำให้เข้าใจผิด
เราเร็วกว่า! (กรุณาไม่สนใจความจริงที่ว่าเราแทบจะเป็นแค่ demo เท่านั้น) ทุกคนรู้เรื่อง 80:20 ความช้าลงจะมาหลังจากที่คุณเริ่มทำทุกอย่างที่คู่แข่งทำ
การถกเถียงนี้สะท้อนถึงรูปแบบที่พบบ่อยในวงการเทคโนโลยี ที่โครงการในช่วงเริ่มต้นมักจะแสดงการปรับปรุงประสิทธิภาพอย่างมากก่อนที่จะนำฟีเจอร์ครบชุดมาใช้งาน สมาชิกในชุมชนบางคนเปรียบเทียบสิ่งนี้กับเครื่องมืออื่นๆ ที่เห็นการลดลงของประสิทธิภาพเมื่อพัฒนาไปสู่ความสมบูรณ์
ข้อจำกัดปัจจุบัน
- รองรับฟีเจอร์ JavaScript เพียง 60% เท่านั้น
- ไม่มี garbage collection
- ไม่รองรับการทำงาน I/O operations
- ไม่เข้ากันได้กับ Node.js API
- อยู่ในระยะพัฒนา pre-alpha
- รองรับ library ecosystem อย่างจำกัด
สถาปัตยกรรมทางเทคนิคจุดประกายการอภิปราย
แนวทางของ Porffor ในการคอมไพล์ JavaScript ไปเป็น WebAssembly เป็น intermediate representation ได้สร้างการอภิปรายทางเทคนิค เครื่องมือนี้กำจัด overhead ของ JavaScript runtime แบบดั้งเดิมโดยการสร้าง native binaries แต่สิ่งนี้มาพร้อมกับการแลกเปลี่ยนที่สำคัญ
ประเด็นที่ถกเถียงกันมากที่สุดคือการขาด garbage collection ในขณะที่นักพัฒนาบางคนเห็นว่าสิ่งนี้ยอมรับได้สำหรับฟังก์ชัน Lambda ที่มีอายุสั้น คนอื่นๆ โต้แย้งว่ามันเปลี่ยนแปลงความหมายของ JavaScript โดยพื้นฐาน ชุมชนแบ่งออกเป็นสองฝ่ายเกี่ยวกับว่าการจัดการหน่วยความจำระดับ request ผ่าน process forking หรือ arena allocation จะสามารถทำงานได้ในทางปฏิบัติหรือไม่
การอภิปรายทางเทคนิคยังมุ่งเน้นไปที่ว่าแนวทางการคอมไพล์ของ Porffor สามารถขยายขนาดเพื่อจัดการกับ edge cases ที่ซับซ้อนของ JavaScript และระบบนิเวศ Node.js อันกว้างใหญ่ที่แอปพลิเคชันการใช้งานจริงส่วนใหญ่พึ่งพาได้หรือไม่
ความพร้อมสำหรับการใช้งานจริงถูกตั้งคำถาม
การนำไปใช้ในองค์กรขนาดใหญ่เผชิญอุปสรรคสำคัญนอกเหนือจากข้อจำกัดทางเทคนิค สมาชิกในชุมชนบางคนแสดงความกังวลว่าบริษัทขนาดใหญ่จะลังเลที่จะนำเครื่องมือทดลองเช่นนี้มาใช้เนื่องจากข้อกังวลด้านความปลอดภัยและเสถียรภาพ สถานะ pre-alpha ของโครงการและการรองรับ JavaScript ที่จำกัดทำให้ไม่เหมาะสมสำหรับแอปพลิเคชันในโลกแห่งความเป็นจริงส่วนใหญ่
อย่างไรก็ตาม ผู้สนับสนุนโต้แย้งว่าโครงการนี้ยืนยันแนวคิดสำคัญเกี่ยวกับการคอมไพล์แบบ ahead-of-time สำหรับ JavaScript พวกเขาแนะนำว่าแม้ว่า Porffor เองจะไม่บรรลุถึงความพร้อมสำหรับการใช้งานจริง แต่มันแสดงให้เห็นแนวทางที่มีค่าซึ่งอาจมีอิทธิพลต่อการพัฒนา JavaScript runtime ในอนาคต
สรุป
การทดลอง Porffor เน้นย้ำถึงความผิดหวังอย่างต่อเนื่องเกี่ยวกับประสิทธิภาพการเริ่มต้นแบบ cold start ของ JavaScript ในขณะที่เปิดเผยความซับซ้อนของการสร้างทางเลือกที่พร้อมสำหรับการใช้งานจริง แม้ว่าตัวเลขประสิทธิภาพจะน่าประทับใจ แต่ชุมชนยังคงแบ่งออกเป็นสองฝ่ายเกี่ยวกับว่าการแลกเปลี่ยนนั้นยอมรับได้หรือไม่ และโครงการสามารถเอาชนะข้อจำกัดปัจจุบันได้หรือไม่
การถกเถียงนี้สะท้อนถึงคำถามที่กว้างขึ้นเกี่ยวกับอนาคตของ JavaScript และว่าการคอมไพล์แบบ ahead-of-time สามารถอยู่ร่วมกับธรรมชาติแบบ dynamic ของภาษาและความต้องการระบบนิเวศที่กว้างขวางได้หรือไม่