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

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- คอมพิวเตอร์อพอลโล 11 ใช้แรมแค่ 4 กิโลไบต์พาคนไปดวงจันทร์
- แอปเดสก์ท็อปยุคนี้มักรันบน Electron และเบราว์เซอร์ Chromium แยกอิสระ
- ความเร็วในการพัฒนาโค้ดถูกให้ความสำคัญมากกว่าประสิทธิภาพการทำงาน
- ระบบปฏิบัติการและแอปพลิเคชันกลายเป็นเครื่องมือดูดข้อมูลผู้ใช้เบื้องหลัง
นิโคเลาส์ เวิร์ท (Niklaus Wirth) เคยกล่าวไว้ตั้งแต่ปี 1995 ว่าซอฟต์แวร์ทำงานช้าลงเร็วกว่าที่ฮาร์ดแวร์จะเร็วขึ้น ในปี 1969 คอมพิวเตอร์นำทางอพอลโล 11 สามารถพา انسان เดินทางข้ามอวกาศ 240,000 ไมล์และลงจอดบนดวงจันทร์ได้สำเร็จด้วยแรมเพียง 4 กิโลไบต์และรอม 72 กิโลไบต์
ตัดภาพมาที่ยุคปัจจุบัน การเปิดแอปพลิเคชันแชทพื้นฐานบนแล็ปท็อปราคา 2,000 ดอลลาร์ กลับต้องเผชิญกับปัญหาความหน่วงและทรัพยากรเครื่องที่ถูกผลาญอย่างมหาศาล ทั้งที่เรามีซีพียูหลายกิกะเฮิร์ตซ์ที่มีมากกว่า 16 คอร์ เอสเอสดีแบบ NVMe ที่ถ่ายข้อมูลได้ 7 กิกะไบต์ต่อวินาที และหน่วยประมวลผล NPU โดยเฉพาะ แต่การคลิกปุ่มในแอปปฏิทินบนเดสก์ท็อปกลับมีความหน่วงสูงถึง 300 มิลลิวินาที และการพิมพ์ในโปรแกรมแก้ไขข้อความบนเว็บก็มักจะเกิดอาการเฟรมเรตตกอยู่เสมอ
ปัญหาซอฟต์แวร์บวมหรือ Bloatware ในปัจจุบันไม่ใช่แค่เรื่องของเว็บแอปพลิเคชันบนเดสก์ท็อป แต่มันคือวิกฤตเชิงระบบหลายชั้นตั้งแต่ระดับฮาร์ดแวร์ซิลิคอนจนถึงอินเทอร์เฟซผู้ใช้ ซึ่งขับเคลื่อนด้วยความสะดวกของนักพัฒนา การสอดส่องข้อมูลขององค์กร และกับดักทางเศรษฐกิจที่ขังผู้ใช้ให้อยู่ในระบบ
เบื้องหน้าของความบวมบนเดสก์ท็อปที่เห็นได้ชัดที่สุดคือการใช้งานรันไทม์เว็บเป็นแอปเดสก์ท็อปอย่างแพร่หลาย นำทัพโดย Electron และสภาพแวดล้อมการประมวลผลที่คล้ายคลึงกัน ในอดีตแอปพลิเคชันเนทีฟจะถูกคอมไพล์ตรงเป็นรหัสเครื่องและเชื่อมโยงกับไลบรารีไดนามิกของระบบปฏิบัติการ เช่น Win32, Cocoa หรือ GTK/Qt แต่ปัจจุบันแทบทุกแอปในซิสเต็มทรายจะรวมเอาโหนดดอทเจเอส, เอ็นจิ้น Chromium V8 และโค้ดเว็บเข้ามาไว้ด้วยกัน
"Software is getting slower more rapidly than hardware becomes faster."
Niklaus Wirth
หากคุณรัน Slack, Discord, VS Code, Spotify และ Microsoft Teams พร้อมกัน คุณไม่ได้กำลังเปิดแอปเนทีฟ 5 แอป แต่คุณกำลังรันเว็บเบราว์เซอร์ที่แยกตัวเป็นอิสระ 5 ตัว ซึ่งแต่ละตัวกินแรมตั้งแต่ 500 เมกะไบต์ถึง 1.5กิกะไบต์ เพียงเพื่อแสดงผลสิ่งที่แท้จริงแล้วคือ HTML และ CSS ที่จัดรูปแบบแล้ว

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การวิเคราะห์เพิ่มเติม: ปัญหาการใช้ทรัพยากรเปล่าประโยชน์ในซอฟต์แวร์ยุคใหม่มักเกิดจากโมเดลธุรกิจที่ต้องการความเร็วในการออกผลิตภัณฑ์สู่ตลาด (Time-to-Market) นักพัฒนาจึงนิยมใช้ชุดเครื่องมือสำเร็จรูปขนาดใหญ่ แทนที่จะเขียนโค้ดภาษาเนทีฟที่ควบคุมหน่วยความจำได้ดีกว่า ส่งผลให้ฮาร์ดแวร์แรงๆ ในปัจจุบันถูกดึงประสิทธิภาพไปใช้กับการจัดการชั้นซอฟต์แวร์ที่ซับซ้อนเกินความจำเป็น แทนที่จะนำไปประมวลผลเพื่อผู้ใช้โดยตรง
การพัฒนาซอฟต์แวร์สมัยใหม่ให้ความสำคัญกับความเร็วในการพัฒนาของนักพัฒนามากกว่าประสิทธิภาพในการรัน แม้ว่าการแลกเปลี่ยนนี้จะสมเหตุสมผลในแง่เศรษฐกิจระยะสั้นสำหรับบริษัทเทคโนโลยี แต่มันก็นำไปสู่ห่วงโซ่การพึ่งพาอาศัยกันที่น่าตกใจ ตัวอย่างเช่น โค้ดของคุณขนาด 50 กิโลไบต์ อาจต้องดึง Dependency A ขนาด 2 เมกะไบต์ที่มีซับดอยนีย์อีกนับสิบตัว และพ่วงด้วย Dependency B ขนาด 15 เมกะไบต์ พร้อมด้วยไลบรารีย่อยเชิงลึกอีกกว่า 1,400 รายการ เพียงเพื่อจัดรูปแบบสตริง แยกวันที่ หรือสร้างกล่องข้อความแนะนำ
นอกจากนี้ ซอฟต์แวร์ในปัจจุบันไม่ได้เป็นเพียงเครื่องมืออีกต่อไป แต่เปรียบเสมือนเครื่องมือดูดข้อมูลเชิงรุก เมื่อคุณเปิดแอปพลิเคชันสมัยใหม่ ทรัพยากรระบบส่วนใหญ่ไม่ได้ถูกใช้เพื่อจัดการกับการป้อนข้อมูลของคุณ แต่ถูกใช้เพื่อวัดพฤติกรรมของคุณ เช่น การติดตามการเคลื่อนไหวของเมาส์ การรวบรวมเทเลเมทรี การแปลงข้อมูลเป็น JSON และการส่งปฏิสัมพันธ์ของผู้ใช้ไปยังเซิร์ฟเวอร์ระยะไกล
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น