ติดตามเวลา build ของนักพัฒนาเพื่อใช้ตัดสินใจว่าจะอัปเกรดเป็น M3 MacBook หรือไม่

 (incident.io)
1 คะแนน โดย GN⁺ 2023-12-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • incident.io ใช้ เวลา build ของ Go แทนความรู้สึกส่วนตัวในการตัดสินใจว่าจะเปลี่ยนโน้ตบุ๊กนักพัฒนาเป็น M3 หรือไม่ และเก็บข้อมูลจริงจาก local development feedback loop
  • เนื่องจาก Go hot reloader เดิมให้ค่าที่ต้องการได้ยาก จึงสร้างเครื่องมือเองและส่ง เหตุการณ์การ build เช่น แพลตฟอร์ม หน่วยความจำ สถานะพลังงาน ขั้นตอนการ build ไฟล์ที่เป็นตัวกระตุ้น และเวลารวม ไปยัง data warehouse
  • จากข้อมูลประมาณ 25k builds ได้คัดทิ้ง build ที่ล้มเหลว ถูกยกเลิก หรือรันบนแบตเตอรี่ แล้ววิเคราะห์ build ที่สำเร็จ 12,525 ครั้ง และยืนยันความแตกต่างทางสถิติว่า build บนไฟ AC เร็วกว่าบนแบตเตอรี่
  • ผลลัพธ์คือ ผู้ใช้ M1 มักต้องรอเกือบ 2 นาทีจน build เสร็จ, M2 ดีขึ้นมากเมื่อเทียบกับ M1, และ M3 ดีขึ้นแบบค่อยเป็นค่อยไปเมื่อเทียบกับ M2
  • แม้ความต่างของหน่วยความจำจะไม่เด่นชัดในเวลา build รวม แต่ใน เวลา linker เครื่องที่มี 32~36GB ได้เปรียบกว่า ทำให้ incident.io ตัดสินใจเปลี่ยนเครื่อง M1 เป็น M3 Pro พื้นฐานพร้อมหน่วยความจำ 36GB

เกณฑ์ตัดสินใจอัปเกรดคือ feedback loop ของการพัฒนา

  • นักพัฒนาทุกคนที่ incident.io ใช้ MacBook สำหรับงานพัฒนา
  • หลัง Apple เปิดตัว M3 MacBook Pro ในเดือนตุลาคม 2023, CTO Pete ระบุว่าจะเปลี่ยนเครื่องถ้าข้อมูลพิสูจน์ได้ว่าคุ้มค่าแก่การอัปเกรด
  • ทีมจึงเตรียม 3 อย่างเพื่อตัดสินใจเรื่องการอัปเกรดเป็น M3
    • Go hot reloader แบบคัสตอม
    • การเก็บ build telemetry จากโน้ตบุ๊กของนักพัฒนา
    • การวิเคราะห์ข้อมูลด้วยโมเดลล่าสุดของ OpenAI และ code interpreter
  • แม้จะวัด productivity ของนักพัฒนาโดยตรงได้ยาก แต่ incident.io มองว่า feedback loop ที่รวดเร็วสำคัญต่อประสิทธิภาพของนักพัฒนา
  • feedback loop ที่เกิดซ้ำบ่อยใน local development มีดังนี้
    • คอมไพล์ Go monolith
    • สร้างโค้ด เช่น API client และ interface
    • hot reload ของฟรอนต์เอนด์และแอปมือถือ
  • นักพัฒนาของ incident.io รันสภาพแวดล้อม incident.io ทั้งหมดแบบโลคัลบนโน้ตบุ๊ก และรักษา feedback loop ต่ำกว่า 30 วินาที จากการแก้โค้ดจนรันได้
  • เนื่องจากแอป Go มี codebase ที่เกือบ 1 ล้านบรรทัด แล้ว การคอมไพล์ Go ซึ่งเกิดบ่อยและมีต้นทุนสูงจึงถูกเลือกเป็นตัวชี้วัดเพื่อเปรียบเทียบประสิทธิภาพ MacBook

วิธีเก็บ build telemetry

  • incident.io ใช้ codegangsta/gin เป็น Go hot reloader มาตั้งแต่เริ่มสร้าง GitHub repository แรก
  • ได้พิจารณา hot reloader ตัวอื่นด้วย แต่ไม่พบเครื่องมือที่ให้ telemetry ที่จำเป็นต่อการวิเคราะห์เวลา build
  • ข้อมูลที่ต้องการเก็บจากแต่ละ build มีดังนี้
    • ระดับระบบ: แพลตฟอร์ม M1/M2/M3, หน่วยความจำรวม เป็นต้น
    • ตัวชี้วัดขณะรัน: OS, การใช้หน่วยความจำ, แหล่งพลังงาน, ระดับแบตเตอรี่ เป็นต้น
    • build telemetry: เวลารวม, ขั้นตอนของ Go build, ไฟล์ที่กระตุ้นให้เกิด build เป็นต้น
  • เนื่องจากไม่มีทางเลือกที่พร้อมใช้ จึงสร้างเครื่องมือเองโดยเริ่มจาก main.go และดึงค่าที่ต้องการด้วยการรันและ parse เอาต์พุตจากไบนารีต่าง ๆ ของ Mac
    • memory_pressure
    • docker
    • sysctl
    • pmset
  • โค้ดที่เกี่ยวข้องเผยแพร่ไว้ใน Gist
  • หลังจากสร้างตัวเก็บข้อมูลระดับระบบและรันไทม์แล้ว ก็ครอบคำสั่ง Go build เพื่อเก็บเวลารายขั้นตอน เช่น linker และ compiler รวมถึงไฟล์ที่เป็นตัวกระตุ้น build
  • hot reloader ตัวสุดท้ายถูกเรียกจาก target make run เดิม และเป็นการเปลี่ยนแปลงที่ทีมวิศวกรรมแทบไม่สังเกตเห็น
  • ทุกครั้งที่ build เสร็จ จะส่ง telemetry event ไปยัง HTTP endpoint และใช้ Fivetran webhook receiver โหลดข้อมูลเข้าสู่ data warehouse

ขั้นตอนการวิเคราะห์ด้วย OpenAI Assistant

  • หลังสะสม dataset ได้มากพอเป็นเวลาหลายสัปดาห์ จึง export ผล select * except(payload) from developer__build_events จาก BigQuery เป็น CSV
  • จากนั้นส่ง prompt อธิบายเป้าหมายและไฟล์ CSV ให้ OpenAI Assistants
  • ใช้โมเดลทดลอง gpt-4-1106-preview พร้อมเปิด code interpreter เพื่อวิเคราะห์ข้อมูล
  • เวลา build มีความผันผวนสูงแม้บนระบบเดียวกัน และยังได้รับผลจาก cache ของ Go compiler มาก จึงไม่ยุติธรรมหากเปรียบเทียบแค่ค่าเฉลี่ยตามแพลตฟอร์ม
    • M3 Max ที่ไม่มี cache อาจช้ากว่า Intel MacBook รุ่นเก่าที่มี cache อยู่แล้วก็ได้
  • การวิเคราะห์จึงไม่ได้เทียบค่าเฉลี่ยอย่างเดียว แต่จัดกลุ่มตามเงื่อนไขของ build และแยกดูตามแพลตฟอร์ม หน่วยความจำ และสถานะพลังงาน

การจัดข้อมูลและเงื่อนไขเปรียบเทียบที่ยุติธรรม

  • dataset ทั้งหมดมีประมาณ 25k builds และถูกรวบรวมจากหลายช่วงเวลา หลายโน้ตบุ๊ก และหลายเงื่อนไขในแต่ละวัน
  • เพื่อเปรียบเทียบแพลตฟอร์มอย่างยุติธรรม จึงตัด build ต่อไปนี้ออก
    • build ที่ล้มเหลวหรือถูกยกเลิก: เป็นงานที่ไม่เสร็จสมบูรณ์ จึงไม่เหมาะกับการเปรียบเทียบความเร็ว build
    • build บนแบตเตอรี่: OS X อาจจำกัดประสิทธิภาพเพื่อยืดอายุแบตเตอรี่
  • หลังตัด build ที่ล้มเหลวออก จำนวน build ที่สำเร็จอยู่ที่ 12,525 ครั้ง
  • ความต่างด้านประสิทธิภาพระหว่าง build บนไฟ AC กับแบตเตอรี่ถูกเปรียบเทียบโดยเน้น M1 Pro และ M2 Max
  • ในการทดสอบทางสถิติ build บนไฟ AC มีเวลาเฉลี่ยต่ำกว่า และได้ p-value ราว 0.0014
  • หลังจากนั้น การวิเคราะห์ทั้งหมดใช้เฉพาะ build ที่สำเร็จและรันบนไฟ AC

ทำไมเวลา Go build จึงแกว่ง

  • Go monolith ของ incident.io เป็นเป้าหมายที่ติดตามประสิทธิภาพการ build อย่างต่อเนื่อง และการลบหรือตั้งค่ากระบวนการ build ให้เหมาะสมก็สำคัญพอ ๆ กับการซื้อฮาร์ดแวร์
  • โปรเจกต์ Go ประกอบด้วยหลายแพ็กเกจ และ Go compiler ใช้ cache เพื่อคอมไพล์ซ้ำเฉพาะแพ็กเกจที่ตัดสินว่ามีการเปลี่ยนแปลง
  • แอปของ incident.io ถูกออกแบบให้มี dependency graph ที่กว้างและมีโมดูลพื้นฐานน้อย เพื่อไม่ให้การเปลี่ยนแปลงส่วนใหญ่ต้องนำไปสู่การคอมไพล์ทั้งกราฟใหม่
  • ประเภทของ build แบ่งคร่าว ๆ ได้ 4 แบบ
    • เสร็จทันที ภายใน 3 วินาที: เป็นการเปลี่ยนแปลงที่ไม่เกี่ยวกับ Go compiler จึงใช้ไบนารีที่ cache ไว้ได้
    • build เร็ว ภายใน 30 วินาที: เป็นการเปลี่ยนแปลงแพ็กเกจเดียวที่มี dependency package น้อย จึงใช้ cache ได้เป็นส่วนใหญ่ และมักเสียเวลาไปกับการลิงก์
    • build ระดับกลาง 30 วินาทีถึง 1 นาที: แก้ไข feature package ที่มี dependency ลงลึกบางส่วน แต่ส่วนใหญ่ยังใช้ซ้ำได้
    • build ช้า มากกว่า 1 นาที: เพิ่ม type ในแพ็กเกจพื้นฐาน domain ทำให้ต้องคอมไพล์ทุกแพ็กเกจของแอปใหม่
  • การเปรียบเทียบแพลตฟอร์มต้องคำนึงถึงลักษณะของ build เหล่านี้ เพราะหากรวม build ทุกแบบเข้าด้วยกันจะกลายเป็นการเปรียบเทียบที่ไม่ยุติธรรม

ผลเปรียบเทียบ M1, M2, M3

  • เมื่อดูเฉพาะ build ที่สำเร็จและรันบนไฟ AC ก็เริ่มจากเปรียบเทียบ M1 Pro กับ M2 Max
  • M2 Max เร็วกว่า M1 Pro อย่างชัดเจนในด้านความเร็ว build แต่ทั้งสองเครื่องต่างกันไม่ใช่แค่ชิปเซ็ต ยังต่างกันที่ การจัดสรรหน่วยความจำ ด้วย
  • การกระจายของ successful build event ตามแพลตฟอร์มและหน่วยความจำมีดังนี้
    • Apple M1 Pro 16GB: 5,235 ครั้ง
    • Apple M2 Pro 16GB: 1,927 ครั้ง
    • Apple M2 Max 32GB: 3,842 ครั้ง
    • Apple M3 Pro 18GB: 321 ครั้ง
    • Apple M3 Pro 36GB: 899 ครั้ง
    • Apple M3 Max 36GB: 301 ครั้ง
  • การเปรียบเทียบระหว่าง M1 Pro 16GB กับ M2 Max 32GB จึงไม่ยุติธรรมเต็มที่เพราะหน่วยความจำต่างกัน
  • เมื่อเปรียบเทียบ M2 Pro 16GB กับ M2 Max 32GB ผลกระทบของหน่วยความจำ 32GB ต่อเวลา build รวมดูค่อนข้างเล็ก
  • M2 Pro และ M2 Max โดยมากใช้ชิปเดียวกัน โดยรุ่น Max มีคอร์ประหยัดพลังงานเพิ่มอีก 2 คอร์
    • คอร์เหล่านี้มีประสิทธิภาพประมาณ 1/5 ของ performance core จึงคาดว่ามีส่วนช่วยต่อการคอมไพล์โปรแกรม Go ไม่มาก
  • เพื่อประเมิน M3 จึงซื้อเครื่อง 3 รุ่นต่อไปนี้
    • M3 Pro 12-core, 6 performance cores + 6 energy efficiency cores, 18GB
    • M3 Pro 12-core, 6 performance cores + 6 energy efficiency cores, 36GB
    • M3 Max 14-core, 10 performance cores + 4 energy efficiency cores, 36GB
  • กราฟเวลา build ของ M3 Pro 18GB และ 36GB คล้ายกัน แต่ข้อมูลของ M3 ยังมีน้อยกว่าแพลตฟอร์มอื่น
  • เมื่อเปรียบเทียบ M3 Pro กับ M3 Max โดยตัด build ที่เร็วมากต่ำกว่า 3 วินาทีออก M3 Max ไม่ได้แสดงการปรับปรุงเด่นชัดพอจะคุ้มกับราคาที่สูงกว่า M3 Pro พื้นฐาน 60%
  • บทสรุปโดยรวมคือ
    • ผู้ใช้โน้ตบุ๊ก M1 มักต้องรอเกือบ 2 นาที จน build เสร็จ
    • M2 เป็น การอัปเกรดครั้งใหญ่ เมื่อเทียบกับ M1
    • M3 เป็น การปรับปรุงแบบค่อยเป็นค่อยไป เมื่อเทียบกับ M2
    • ผู้ใช้ M1 จะอัปเกรดเป็น M3 Pro พื้นฐาน
    • ผู้ใช้ M2 ยังไม่จำเป็นต้องอัปเกรด

หน่วยความจำเห็นผลชัดกว่าในเวลา linker

  • ในการเทียบเวลา build รวม ไม่เห็นการปรับปรุงที่มีนัยสำคัญมากนักเมื่อเพิ่มจาก 16~18GB เป็น 32~36GB
  • เนื่องจากผลของหน่วยความจำไม่เด่นชัดบนกราฟอย่างที่คาด จึงแยกวิเคราะห์ เวลา linker ออกมาต่างหาก
  • telemetry event มีเวลาในขั้นตอน link และ compile อยู่แล้ว จึงสร้างคอลัมน์ linker_time จาก build_stages.link.duration_seconds เพื่อวิเคราะห์
  • เมื่อเปรียบเทียบ linker_time ตามแพลตฟอร์มและการจัดสรรหน่วยความจำ ก็พบรูปแบบที่ต่างออกไป
    • เครื่อง M1, M2, M3 ที่มีหน่วยความจำ 32~36GB เกือบทั้งหมดจบการลิงก์ได้ใน ต่ำกว่า 20 วินาที
    • เครื่องที่มีหน่วยความจำ 18GB หรือน้อยกว่า มักเกิดกรณีที่การลิงก์ใช้เวลามากกว่า 20 วินาทีบ่อยครั้ง
  • จึงยืนยันได้ว่าแม้การเพิ่มหน่วยความจำจะเห็นผลไม่ชัดในเวลา build รวม แต่มีประโยชน์ในขั้นตอน linker
  • ทีมยังกำลังพิจารณาทางเลือกในการถอด Docker ออกจากเครื่องพัฒนา และตีความได้ว่าเครื่องที่มีหน่วยความจำน้อยอาจปรับปรุงเวลา linker ได้ด้วยการเพิ่ม system memory ที่ใช้งานได้ผ่านการไม่ใช้ Docker
  • ในงานพัฒนาแอปมือถือ simulator ใช้ system memory จำนวนมาก การเพิ่มหน่วยความจำจึงถือว่าคุ้มค่าสำหรับอนาคตด้วย

การตัดสินใจสุดท้ายและผลพลอยได้

  • incident.io ตัดสินใจอัปเกรดเครื่อง M1 เป็น M3 Pro พื้นฐานที่มีหน่วยความจำ 36GB
  • เครื่อง M2 ดูมีประสิทธิภาพดีพออยู่แล้ว จึงยังไม่อัปเกรดในตอนนี้
  • นอกจากช่วยตัดสินใจเรื่องการซื้อโน้ตบุ๊กแล้ว ยังช่วยให้เข้าใจสภาพแวดล้อมและเครื่องมือพัฒนามากขึ้นด้วย
  • สิ่งที่ทีมได้จากงานนี้มีดังนี้
    • พบว่าเวลา Go build เป็น benchmark ที่ดีในการวัดประสิทธิภาพของเครื่องนักพัฒนา
    • สร้าง Go hot reloader ของตัวเองเพื่อติดตาม metrics ที่ต้องการ และได้การปรับปรุงด้าน usability อื่น ๆ เพิ่มเติม
    • เข้าใจปัจจัยที่ทำให้ Go build เร็วขึ้นหรือช้าลงได้ดีขึ้น
    • ยืนยันว่า OpenAI Assistants สามารถใช้กับโจทย์วิเคราะห์ข้อมูลลักษณะคล้ายกันได้
    • วัดการปรับปรุงของแต่ละสายชิป Apple ในมุมมองของนักพัฒนา Go ได้เชิงปริมาณ
    • หน่วยความจำยังสำคัญ แต่เห็นผลชัดกว่าในเวลา linker มากกว่าเวลา build รวม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-30
ความคิดเห็นจาก Hacker News

  • เป็นบทความที่ยอดเยี่ยม และชอบที่ใช้วิธีเก็บและวิเคราะห์ข้อมูลหลากหลายแบบ แต่ผมคิดว่าน่าจะง่ายและแม่นยำกว่ามากถ้าวางโน้ตบุ๊กแต่ละเครื่องไว้ข้าง ๆ กัน แล้วรัน บิลด์แบบจับเวลา ในสถานการณ์เดียวกัน
    น่าจะสร้างสคริปต์ได้ภายในวันเดียวเพื่อเปรียบเทียบหลายกรณี เช่น บิลด์ทั้งหมด, บิลด์แบบ incremental ของส่วนที่เปลี่ยนล่าสุด, บิลด์แบบ incremental ที่ต้องรีบิลด์โมดูลเฉพาะ หรือไล่ apply Git commit ล่าสุด 100 รายการตามลำดับแล้วจับเวลาบิลด์แบบ incremental
    การรวบรวมสถิติทั้งบริษัทอาจทำให้เกิด bias สูงได้ เช่น พนักงานใหม่มีแนวโน้มใช้ M3 ส่วนพนักงานเก่าใช้ M1 และพนักงานใหม่อาจทำการเปลี่ยนแปลงเล็ก ๆ มากกว่า ขณะที่คนมีประสบการณ์จัดการโค้ดส่วนลึกหรือบริเวณที่ซับซ้อนกว่า ทำให้เวลาบิลด์ยาวขึ้นได้
    ดังนั้นตัวการวิเคราะห์เองดูดี แต่เมื่อคิดถึง bias ที่แฝงอยู่ในกลุ่มตัวอย่างแล้ว ผมเห็นว่าควรเริ่มจากวิธีง่าย ๆ อย่างการ benchmark commit ล่าสุด ๆ บนโน้ตบุ๊กแต่ละเครื่อง ก่อนจะสร้างสถาปัตยกรรมเก็บข้อมูลทั้งบริษัท

    • เห็นด้วยกับข้อเสนอทั้งหมด และในฐานะคนเขียนบทความ ผมได้ spot check ประสิทธิภาพของงานทั่วไปบางอย่างก่อนแล้ว
      เหตุผลที่เก็บข้อมูลนี้ไม่ใช่แค่เพื่อเทียบกันระหว่างเครื่อง แต่เพื่อสะสมข้อมูลย้อนหลังของเวลา build ของนักพัฒนา และวัดประสิทธิภาพการ build อย่างต่อเนื่องเพื่อจับ regression
      เมื่อเห็นว่าเวลาบิลด์เพิ่มขึ้น เราก็มักปรับโครงสร้าง codebase เพื่อให้บิลด์เร็วขึ้น
    • ไม่เห็นการวิเคราะห์ network build ในฐานะทางเลือกแทน M3 เลย โปรเจกต์ของผมมีประมาณ 40 ล้านบรรทัด และเมื่อเกินเกณฑ์หนึ่งไปแล้ว ต่อให้เครื่อง local เร็วแค่ไหนก็สู้ network build ที่ทีม infrastructure ทำไว้ไม่ได้
      M3 อาจทำให้บิลด์เร็วกว่า M1 ได้ 30% แต่ network build เร็วกว่า 15 เท่า จึงควรพิจารณาได้ว่าควรลงทุนกับ network build แทนการให้ M3 แก่นักพัฒนาหรือไม่
    • bias ของกลุ่มตัวอย่างเป็นปัญหาเรื่อง วิธีวิทยาการวิเคราะห์ เรื่องนี้แสดงให้เห็นว่าถ้าคุณไม่ได้เข้าใจหัวข้อนั้นดีพอด้วยตัวเอง ก็พึ่งพาผู้ช่วย AI ไม่ได้
      มีการทำ t-test กับข้อมูลที่ไม่ได้สุ่มตัวอย่างอย่างเป็นอิสระ โดย data point หลายจุดมาจากคนต่างกัน และแต่ละคนทำงานต่างกัน จึงอาจมีปริมาณการคำนวณที่ต้องใช้ต่างกันจนเกิด confounding factor ได้ สิ่งนี้ละเมิดสมมติฐานพื้นฐานของ t-test แต่ code interpreter ไม่ได้ชี้ให้เห็น
      แทนที่จะทำแบบนั้น สามารถใช้ linear mixed-effects model โดยใส่ปัจจัยอย่างเจ้าของโน้ตบุ๊กและอายุงานเป็น random effects ได้
      ถึงอย่างนั้น ตัวข้อมูลเองก็น่าสนใจ โดยเฉพาะส่วนของ RAM ที่น่าสนุกมาก cache มีพลังมาก และการมี RAM มากให้ประโยชน์มากกว่าที่คนทั่วไปคิด โดยปกติ MacBook ที่มี RAM มากกว่าที่จำเป็น จะมี RAM ส่วนที่เหลือส่วนใหญ่ถูกใช้เป็น cache
    • ด้วยเหตุผลบางอย่าง ดูเหมือนว่าเลือกวิธีที่แพงที่สุดเท่าที่จะเป็นไปได้เพื่อตอบคำถามนี้ และยังสงสัยด้วยว่าทำไมเมื่อสรุปว่า M2 ก็เพียงพอแล้ว ข้อสรุปกลับเป็นการอัปเกรดผู้ใช้ M1 ไปเป็น M3 ที่แพงกว่า
    • น่าจะบันทึกไว้ด้วยว่าสร้างอะไรและอย่างไร เช่น “repository เริ่มที่ commit นี้”, “apply diff นี้”, “รัน build ด้วยคำสั่งนี้”
      ถ้าเก็บสักประมาณหนึ่งสัปดาห์ ก็จะได้ภาพตัดขวางของ workload จริง และสามารถนำ build เหล่านั้นไปรันซ้ำในฮาร์ดแวร์แต่ละระดับ รวมถึงนำกลับมาใช้กับฮาร์ดแวร์ใหม่ในภายหลังได้

  • ในฐานะนักวิทยาศาสตร์ ผมรู้สึกว่าวิธีที่โปรแกรมเมอร์คอมพิวเตอร์จัดการกับข้อมูลนั้นน่าสนใจ
    มีการวาดกราฟสวย ๆ ใช้ ChatGPT ทำ automation การวิเคราะห์ได้เร็วมาก และ ChatGPT ก็ให้ t-test ที่ดูค่อนข้างสมเหตุสมผล
    แต่ทั้งที่มีความแปรผันตามหน่วยความจำและชนิดชิป กลับไม่ได้คิดถึง linear regression และเลือกวาด histogram ที่เปรียบเทียบได้ยาก อาจเสริมด้วยค่าเฉลี่ยแบบง่าย ๆ กับ error bar หรือใช้ cumulative distribution function (CDF) ที่ดูการซ้อนทับหรือการเลื่อนได้ง่ายกว่า

    • ในฐานะนักวิจัยด้านวิทยาการคอมพิวเตอร์ ผมก็มีปฏิกิริยาเหมือนกัน ตอนปริญญาตรีผมเรียนเอกคู่ชีววิทยา/วิทยาการคอมพิวเตอร์และเรียนสถิติด้วย แต่คิดว่าผมมาใช้ cumulative distribution function ในการวิเคราะห์ข้อมูลตอนเรียนบัณฑิตศึกษา
    • โดยปกตินั่นเป็นงานของ data scientist และทีม engineering infrastructure ส่วนใหญ่ไม่มี data scientist อีกทั้งส่วนใหญ่ก็ไม่จำเป็นต้องมีตลอดเวลา
      โดยทั่วไปเราจัดการข้อมูลตามที่เครื่องมือแสดงให้ดู ซึ่งก็เกี่ยวข้องไม่น้อยกับชุดซอฟต์แวร์ด้าน analytics, performance analysis และ observability
      การคาดหวังให้ software engineer ทั่วไปรู้จัก CDF ก็คล้ายกับการคาดหวังให้รู้พื้นฐานการเขียน quaternion หรือ shader ในกราฟิก 3D
    • distribution ดูเหมือนไม่ใช่ normal distribution อย่างชัดเจน และ ความต่างของ median ก็น่าจะสำคัญไม่น้อย ขั้นแรกผมน่าจะใช้ Wilcoxon test
      หรือจะใช้ quantile regression ก็ได้ ถ้ามีสมมติฐานว่า M3 > M2 > M1 การทดสอบ Jonckheere–Terpstra ที่มีชื่อเสียงสำหรับ median แบบมีลำดับ อาจเหมาะมากกับการวิเคราะห์กึ่ง ๆ แบบนี้
    • บางจุดใช้ box plot ซึ่งเปรียบเทียบได้ชัดเจนกว่า ถ้าแสดงข้อมูลทั้งหมดด้วย box plot น่าจะได้ผลดีกว่า
    • สำหรับการเปรียบเทียบแบบนี้ ผมอยากแนะนำกราฟ empirical cumulative distribution function แต่ละ distribution จะเป็นเส้นโค้งหนึ่งเส้น และสามารถวางหลายเส้นบนกราฟเดียวกันเพื่อเปรียบเทียบได้ง่าย
      ดูตัวอย่างได้ที่กราฟสุดท้ายในหน้านี้: https://ggplot2.tidyverse.org/reference/stat_ecdf.html

  • เป็นการวิเคราะห์ที่หนักแน่น แต่จากประสบการณ์ส่วนตัว อยากเตือนไว้ข้อหนึ่ง
    ที่บริษัทซอฟต์แวร์ขนาดกลางซึ่งมีพนักงาน 2,000 คน เราพยายามเพิ่มผลิตภาพของนักพัฒนา และสำรวจแนวทางย้าย development stack ไปไว้บน AWS instance แทนการซื้อโน้ตบุ๊กใหม่
    สุดท้ายมันกลายเป็น โปรเจกต์หลายปี ที่มีนักพัฒนาราว 4 คนทำเต็มเวลา และพอมองย้อนกลับไปก็ไม่คุ้มต้นทุน การจำลองประสบการณ์พัฒนาแบบ local ล้วน ๆ บนคลาวด์ยังยากเกินไป
    ดังนั้นผมคิดว่าอัปเกรดโน้ตบุ๊กน่าจะดีกว่า

    • ทีมของเราพัฒนากับ K8s cluster แบบ remote ทั้งหมดมาหลายปีแล้ว และให้ developer experience ที่ค่อนข้างทรงพลัง
      โค้ดอยู่บนโน้ตบุ๊ก แต่ซิงก์แบบเรียลไทม์กับ remote service โดยไม่ต้องทำ Docker build หรือ deploy ไป K8s จึงให้ความรู้สึกเหมือน local จริง ๆ
      โดยเฉพาะระหว่างเขียนโค้ดสามารถรันตั้งแต่ integration test ขึ้นไปได้ทันที ทำให้เลี่ยงวงจร commit-push-pray ได้
      เราใช้ Garden(https://docs.garden.io) เพื่อสิ่งนี้ ไม่ว่าจะใช้ Garden หรือไม่ ถ้ามีเครื่องมือที่เหมาะสม การใช้พลังของคลาวด์ใน inner development loop ก็ทำได้ยอดเยี่ยมทีเดียว
      บทความที่เขียนประสบการณ์ไว้เพิ่มเติม: https://thenewstack.io/one-year-of-remote-kubernetes-develop...
    • อาจเกี่ยวกับขนาดองค์กรด้วย บริษัทเรามีพนักงานประมาณ 7,000 คน และเริ่มเดินเส้นทางคล้ายกันเมื่อไม่กี่ปีก่อน ใช้เวลาพอสมควรกว่าที่ remote จะดีกว่า local แต่ตอนนี้ดีกว่าอย่างชัดเจน
      หลายอย่างที่ทำไม่ได้ในเวอร์ชัน local-only ก็ทำได้แล้ว เช่น เวลาเปลี่ยนไปมาระหว่างหลาย branch แทนที่จะเปลี่ยนไฟล์ local ก็เปลี่ยนเครื่อง ทำให้ delay ในการสลับงานต่ำลงมาก
    • เห็นด้วยอย่างเต็มที่ ถ้าไม่สามารถรันโซลูชันทั้งหมดแบบ local ได้ จะเกิด friction มหาศาลในการทำความเข้าใจและใช้เหตุผลเกี่ยวกับโซลูชันนั้น
      ถ้าจะทำอะไรสักอย่างแล้วต้องเปิดชิ้นส่วนมากกว่า 200 ชิ้น แม้แต่การทำงานกับส่วนเดียวที่เชื่อมกับแค่ไม่กี่ส่วนก็ยังยาก
      ในยุคที่มีเซิร์ฟเวอร์ 128 core ขึ้นไป, 256 thread ขึ้นไป ผมเริ่มเอนเอียงกลับไปคิดว่า monolith ดีกว่าสำหรับซอฟต์แวร์ส่วนใหญ่
    • บริษัทเรามี antivirus บน Linux และของจิปาถะอื่น ๆ ที่ยัดใส่ cloud developer box อย่างไม่คิดมากเกินไป จนแม้จะใช้ instance type ขนาดใหญ่ build ก็ยังช้ากว่าโน้ตบุ๊กมากกว่า 10 เท่า และช้ากว่าเครื่องพัฒนาจริง ๆ อย่าง Threadripper หลายร้อยเท่า
      เป็นการเสียเงินและเวลาเปล่า ๆ จะเห็นได้ว่าการ hook system call ทุกตัวด้วยซอฟต์แวร์ไร้สาระจาก vendor นั้นแย่ต่อ toolchain แบบ Unix ที่รัน subprocess จำนวนมาก
    • ผมมองว่านี่ใกล้เคียงกับปัญหาด้านบุคลากรมากกว่า
      ในบริษัทเทคโนโลยีขนาดใหญ่อย่าง Google, Meta สภาพแวดล้อมพัฒนาอยู่บนคลาวด์ สำหรับ software engineer ส่วนใหญ่
      เป็น developer experience ที่ดีกว่า local มาก

  • ถ้าอิงงานพัฒนา iOS และคำนึงถึงต้นทุนด้วย ข้อสรุปจากการสำรวจส่วนตัวของผมเป็นแบบนี้
    M2 Pro ดี แต่เมื่อเทียบกับ M1 Pro 10-core แล้ว ส่วนต่างการพัฒนาไม่ได้ใหญ่มาก ตาม XcodeBenchmark คือ 136 วินาที เทียบกับ 120 วินาที: https://github.com/devMEremenko/XcodeBenchmark
    M3 Pro ให้ความรู้สึกเหมือนถูกลดทอนเพื่อแยกขายจาก M3 Max และมี performance core แค่ 6 ตัว จึงแทบจะใกล้เคียงกับ M2 Pro
    สุดท้ายผมซื้อ M1 Pro 10-core มือสองสภาพค่อนข้างใหม่ และพอใจมาก ได้ประสิทธิภาพ 85% ในราคาต่ำกว่าครึ่งของ M3 Pro รุ่นพื้นฐาน และยังคำนึงด้วยว่าโดยทั่วไป CPU ต้องเร็วขึ้นอย่างน้อย 33–50% ถึงจะรู้สึกถึงความต่าง

    • เรื่องที่ว่า M3 Pro ถูกลดทอนถูกพูดซ้ำบนอินเทอร์เน็ตมาตลอดตั้งแต่เปิดตัว แต่ในความเป็นจริงมันเป็นตัวเลือกที่ยอดเยี่ยม
      มีประสิทธิภาพต่อพลังงานดีกว่า M2 Pro มาก และ performance ก็สูงกว่าเล็กน้อย สิ่งที่ผมต้องการจากโน้ตบุ๊กคือแบบนั้น ส่วน memory bandwidth ไม่ค่อยได้ใช้เท่าไร
    • ประสบการณ์ของผมก็คล้ายกัน ในเวลา compile จริง M1 Pro ยังอยู่ค่อนข้างใกล้กับรุ่น M2, M3 สำหรับโน้ตบุ๊กในปัจจุบัน
      ไม่ได้ต่างกันมากเท่าที่บทความนี้แสดงให้เห็น อาจขึ้นกับภาษาและโปรเจกต์ แต่เมื่อ benchmark คำสั่ง compile เดียวกันแบบเทียบข้างกัน ผมไม่เห็นความต่างใหญ่ขนาดนี้
    • น่าสนใจที่การพัฒนาของ M2 น้อยกว่าที่เห็นในบทความนี้
      เพราะ compile toolchain ต่างกันจึงไม่น่าแปลกใจ และใน Go toolchain ก็เห็นได้ว่า spec บางอย่างส่งผลต่างกันในแต่ละขั้นตอน build เช่น memory ที่เพิ่มขึ้นช่วย performance ของ linker
      ผมเห็นหลายครั้งว่ามีปฏิกิริยาว่า performance ของ M3 ถูกจำกัดอย่างประหลาด หวังว่าจะไม่เป็นแบบนี้ต่อในรุ่นหลัง M4
    • ช่วงนี้ผมคำนวณแบบเดียวกัน และสุดท้ายซื้อ M1 Pro ที่อัป memory และ disk เต็มสุดมา เป็นดีลที่ดีและเป็นคอมพิวเตอร์ที่ยอดเยี่ยม
    • ผมชอบ M1 MacBook Air สำหรับงานพัฒนา iOS สิ่งที่อยากได้จากไลน์ Pro มีแค่หน้าจอ โดยเฉพาะ PPI
      120Hz ก็ดีถ้ามี แต่คงไม่ได้มาอยู่ในโน้ตบุ๊ก Air

  • เคยเป็นผู้ร่วมพัฒนาหลักของ Chromium และ Node.js และปัจจุบันเป็นผู้ร่วมพัฒนาหลักของ gRPC Core/C++ แต่ไม่เคยรู้สึกกังวลมากนักเรื่อง เวลา build
    มีทั้ง “interactive build” ซึ่งเป็น incremental build สำหรับรัน unit test ที่เกี่ยวข้องซ้ำระหว่างทำงาน และ non-interactive build ที่สั่งรันไว้แล้วไปดื่มกาแฟหรืออ่านอีเมล ไม่เคยเห็นว่าการเปลี่ยนฮาร์ดแวร์จะทำให้ non-interactive build กลายเป็น interactive build ได้
    เครื่องส่วนตัวเป็น Intel i7 กับหน่วยความจำ 16GB ที่อายุมากกว่า 5 ปี แต่พอรู้ว่าการ link Node.js บน WSL ต้องใช้หน่วยความจำมากกว่านี้ จึงเพิ่มอีก 16GB
    โน้ตบุ๊กที่ใช้ทำงานเป็น Intel MacBook Pro ที่มี Touch Bar และไม่คิดว่ามันมีผลต่อ productivity มากนัก สิ่งสำคัญคือขนาดและคุณภาพของหน้าจอ กับความเร็วของ storage ผลกระทบจาก build system เช่นความเร็วของ incremental build และการรองรับ distributed build ใหญ่กว่าความก้าวหน้าของ CPU สำหรับโปรเจกต์ส่วนตัวใช้ Bazel

    • ดูเหมือนโปรแกรมเมอร์จะยอมรับไปแล้วว่า แม้แก้ไขเล็กน้อยมากในฟังก์ชันเดียวจน binary เปลี่ยนไปแค่ไม่กี่ byte แต่ compile และ link ก็ยังใช้เวลานาน
      จริง ๆ แล้ว compile และ link ควรเสร็จแทบจะทันที และควรเร็วขนาดที่แทบไม่รู้สึกว่ามีขั้นตอน compile อยู่
      release build ที่มีเทคนิคอย่าง whole-program optimization จะใช้เวลานานก็ไม่เป็นไร แต่ loop compile/debug/test ทั่วไปสามารถเป็นแบบทันทีได้ การ compile ของภาษา system ช้าอย่างไม่น่าเชื่อด้วยเหตุผลเชิง legacy แต่ไม่ได้จำเป็นต้องเป็นแบบนั้น
    • ผมเองก็เคยใช้ Blaze แล้วพยายามลองใช้ Bazel กับโปรเจกต์ส่วนตัว แต่โปรเจกต์นั้น backend กับ frontend ถูกทำเป็น Docker หมด ทำให้ build rule กลายเป็นอะไรที่แปลกและเฉพาะทางอย่างรวดเร็ว
      พอใช้เวลามากกับการแก้ไฟล์ BUILD ก็เริ่มสงสัยว่ามันมีค่ามากกว่า Makefile ธรรมดาหรือไม่ เรื่องนี้เกิดเมื่อ 3 ปีก่อน ดังนั้น ecosystem สาธารณะตอนนี้อาจดีขึ้นแล้วก็ได้
    • ผมว่า M series น่าจะเหนือกว่า Intel MBP อยู่พอสมควรทั้งเรื่องหน้าจอและความเร็ว storage ตอนย้ายจาก Intel MBP ไป M1 สำหรับเครื่องทำงาน หน้าจอดีขึ้นอย่างชัดเจนมาก
      ความเร็ว storage ไม่แน่ใจ เพราะ build ของเราทั้งหมดรันบนเครื่องพัฒนา remote ที่แรงมาก
    • เป็นเพราะคุ้นกับ Bazel ไปแล้วนั่นแหละ ผมก็เคยเป็นแบบนั้น
    • Chromium เป็นโปรเจกต์ขนาดมหึมา ถ้าเป็นโปรเจกต์ที่มีขนาดทั่วไปกว่านี้ ก็สามารถทำ full build บนโน้ตบุ๊กได้ภายในเวลาที่สมเหตุสมผล

  • สำหรับคนที่พยายามทำ การวิเคราะห์ข้อมูลด้วย AI อย่างในบทความ ผมคิดว่าการใส่ข้อมูลเข้า R หรือ Stata แล้ว query เองโดยตรงง่ายกว่ามาก
    คำสั่งสั้นกว่า แม่นยำกว่า และเหนือสิ่งอื่นใดคือทำซ้ำได้มากกว่า
    สิ่งที่ยากที่สุดในการวิเคราะห์ข้อมูลคือการเข้าใจข้อมูลและกลไกที่สร้างข้อมูลนั้นขึ้นมา การจะทำแบบนั้นต้องมี causal model ของโดเมนปัญหา
    ถ้า AI ไม่ได้ถูกฝึกมาก่อนด้วยข้อมูลอื่น ๆ ในโดเมนนั้น ผมไม่แน่ใจว่าจะสร้าง causal model ที่มีประโยชน์ได้หรือไม่ หากไม่มี model นั้น ก็เป็นไปไม่ได้ที่จะตีความข้อมูลอย่างสมเหตุสมผล และผมก็สงสัยว่า AI model ปัจจุบันสามารถตรวจจับ confounding, อิทธิพลของ outlier ที่มากเกินไป และตัวแปร effect modifier ที่น่าสนใจได้หรือไม่

    • ผู้ช่วย AI ที่ใช้ GPT-4 โดยพื้นฐานแล้วกำลังทำงานนั้นอยู่
      ตอนผมทำคือใช้ Python กับ pandas และสามารถขอให้แสดง code ที่ใช้ในการวิเคราะห์ได้
      ความต่างคือจะใส่ข้อมูลเข้า R/Python แล้วค้นว่า “ทำ xyzzzy อย่างไร” เพื่อเขียน code เอง หรือจะใช้ ChatGPT

  • ส่วนที่ว่า “นักพัฒนาทุกคนสามารถรันสภาพแวดล้อม incident.io เต็มรูปแบบแบบ local บนโน้ตบุ๊ก และได้ feedback loop ต่ำกว่า 30 วินาทีตั้งแต่แก้ code จนถึงรัน” ดูเป็นความสำเร็จที่ใหญ่ที่สุด
    ยกเว้นกรณีที่เคยช่วย startup ชั่วคราว ผมไม่เคยอยู่บริษัทไหนที่สามารถรัน instance สำหรับ development/local ของทั้งบริษัทบนเครื่องเดียวได้
    มักจะมีบางอย่างที่เข้าถึงไม่ได้เสมอ และมักมีหลุมพรางอยู่ตลอด

    • ก่อนงานล่าสุด ผมไม่สามารถรันแอปเจ้ากรรมนั้นแบบ local ได้ และมันทำให้แทบคลั่งจริง ๆ
      ไม่เข้าใจว่าทำไมคนถึงไม่โกรธกับ developer experience ที่เลวร้ายแบบนี้มากกว่านี้ คนรุ่นใหม่ที่เพิ่งจบมหาวิทยาลัยสมัยนี้ดูเหมือนจะไม่รู้ว่าตัวเองพลาดอะไรไป
    • ผมเคยทำงานในบริษัทแบบนั้น และหลังจากออกมาก็คิดถึงมันมากจริง ๆ
      คนที่ไม่เคยอยู่ในโลกแบบนั้นจะไม่เข้าใจว่ามันดีกว่ามากแค่ไหน และจะหาเหตุผลมารองรับได้สารพัดแบบ
    • นึกภาพยากมากว่าถ้าไม่มีสิ่งนี้จะเป็นอย่างไร เรารันทุกอย่างแบบ local ด้วย k3s และใช้งานได้ดี
      แต่อย่างไรก็ตาม ปีที่แล้วเราเพิ่ม Snowflake เข้ามา ซึ่งแม้จะช่วยแก้ปัญหาจริงได้ แต่การพัฒนาแบบวนซ้ำในส่วนนั้นเป็นเรื่องเจ็บปวด
    • เมื่อก่อนทำได้ แต่เมื่อ scale โตขึ้นก็ support ได้ยาก ระดับความพยายามจะเพิ่มขึ้นประมาณกำลังสองตามขนาดบริษัท
      มันเพิ่มเป็นเส้นตรงตามจำนวน service ที่ต้อง support และก็เพิ่มเป็นเส้นตรงตามจำนวน engineer ที่ต้อง support ด้วย อีกทั้งยังเกิด use case หลากหลายที่ไม่ค่อยเข้ากัน และในไม่ช้าทีม infra ก็กลายเป็นคอขวดของการปล่อยฟีเจอร์ แล้วผู้คนก็เริ่มใช้วิธีของตัวเองคนละแบบ
      เมื่อกล่องแพนโดร่านั้นถูกเปิดแล้ว แทบเป็นไปไม่ได้ที่จะย้อนกลับ ถึงอย่างนั้น การลด development cycle จากหลายชั่วโมงหรือหลายวันเหลือไม่กี่นาที ก็สำคัญกว่าการลดเวลาจากไม่กี่นาทีลง 25% มาก
    • ในแอปที่กำลังทำอยู่ตอนนี้ ผมพยายามเต็มที่เพื่อให้ทำสิ่งนี้ได้ ต้องรัน object detection model กับ Stable Diffusion เลยต้องโน้มน้าว CEO ว่า M2 Max จะช่วยได้
      จนถึงตอนนี้ก็ไปได้ดี

  • ในฐานะผู้เขียน ขอบคุณที่เอามาโพสต์
    มีหลายเรื่องอยู่ในนั้น เช่น profiling การ compile ของ Go, การทำ hot reloader, การวิเคราะห์ dataset ของ build ด้วย AI
    สรุปคือ M1 คุ้มค่าที่จะอัปเกรดเป็น M3 Pro และในการทดสอบ Max ไม่ได้สร้างความแตกต่างมากนัก M2 ค่อนข้างใกล้เคียงกับ M3 จึงไม่คุ้มที่จะอัปเกรดสำหรับเรา
    ถ้ามีคำถามก็ยินดีตอบ

    • ขอบคุณสำหรับการวิเคราะห์ละเอียด ๆ และอยากรู้ว่าได้คำนวณ ต้นทุนเวลา engineering ที่ใช้กับการวิเคราะห์นี้หรือไม่
      และอยากรู้ด้วยว่าต้นทุนนั้นส่งผลต่อระยะเวลาคืนทุนอย่างไร
    • อยากรู้ว่าคุณสรุปได้อย่างไรว่า SKU Max ไม่ได้เร็วขึ้นมาก การกระจายในกราฟดูเหมือนจะเร็วกว่า แต่ข้อความด้านล่างบอกแค่ว่าดูคล้ายกัน
    • อยากรู้ว่าควรมองว่าเหตุผลที่ M3 Max มีข้อได้เปรียบน้อย เป็นเพราะ workload ใช้ core ได้ไม่เต็มที่หรือไม่
      หรืออาจเป็นเพราะงานจบเร็วเกินไปจนในการใช้งานจริงไม่เห็นความต่างก็ได้
    • อยากรู้ว่าผู้จัดการเลื่อน deliverable บางอย่างออกไปเพื่อให้มีเวลาทำงานนี้หรือเปล่า หรือทำแบบ งานเสริม
    • เป็นการเปรียบเทียบที่น่าสนใจ ถ้าเป็นไปได้ อยากเห็น build เพิ่มเติมบนเครื่องที่มี หน่วยความจำ 8GB ด้วย

  • ไอเดียน่าสนใจ แต่คุณภาพของการวิเคราะห์ข้อมูลดูค่อนข้างต่ำ และไม่แน่ใจว่าจริง ๆ แล้วกำลังได้เรียนรู้สิ่งที่คิดอยู่หรือไม่
    โดยเฉพาะเมื่อขยับจาก M1 Pro ไป M2 Pro ก็เข้าใจยากว่าทำไมบิลด์ที่ใช้เวลาต่ำกว่า 20 วินาทีจึงเพิ่มขึ้นอย่างมากขนาดนั้น ความต่างด้านประสิทธิภาพจริงของทั้งสองในการคอมไพล์โค้ดอยู่ราว ๆ 20–25%
    การที่เครื่อง M3 มีบิลด์ต่ำกว่า 20 วินาทีน้อยกว่าเครื่อง M2 หรือ M3 Pro ที่มีคอร์เพียงครึ่งหนึ่งกลับมีบิลด์ต่ำกว่า 20 วินาทีมากกว่า M3 Max ก็ฟังดูไม่สมเหตุสมผลนัก
    เป็นไปได้สูงว่า ความแตกต่างด้านพฤติกรรมของนักพัฒนา เช่น คนที่ใช้โน้ตบุ๊กคนละรุ่นมักทำงานคนละประเภทกัน เป็นสิ่งที่ทำให้เกิดความต่างเหล่านี้
    จากข้อสังเกตบางอย่างหลังอ่านคร่าว ๆ ดูเหมือนว่า Go compiler จะใช้ประโยชน์จากคอร์เพิ่มเติมได้ไม่มากนัก วิธีรวมข้อมูลก็ไม่สะดวกโดยพื้นฐาน และวิธีเปรียบเทียบก็ขาดความสอดคล้อง เพราะผสมทั้งฮิสโตแกรมกับกราฟความหนาแน่นแบบแบ่งช่วง แถมช่วงแกน y ยังต่างกันด้วย
    Mac ไม่ได้ throttle ประสิทธิภาพ CPU เพียงเพราะอยู่ในสถานะแบตเตอรี่ ถ้าบิลด์ช้าลงจริงเมื่อใช้แบตเตอรี่ แม้จะยืนยันจากกราฟอย่างเดียวได้ยาก แต่ก็น่าจะเป็นเพราะเปิดการตั้งค่า “ประหยัดพลังงาน” ไว้

    • M3 มีแบนด์วิดท์หน่วยความจำน้อยกว่า ดังนั้นในบางกรณีการใช้งานจึงถือเป็น การดาวน์เกรด โดยแท้จริง

  • ออกนอกเรื่องเล็กน้อย แต่สงสัยว่าบริษัทอื่น ๆ ถ่วงดุลระหว่างการจัดการ endpoint กับซอฟต์แวร์ความปลอดภัย และ ประสิทธิภาพการทำงานของนักพัฒนา กันอย่างไร
    บริษัทของเรารันบริการเบื้องหลังมากกว่า 5 ตัวบนโน้ตบุ๊กของนักพัฒนาทั้ง Mac และ Windows มีทั้งการจัดการ endpoint, การดักจับการยกระดับสิทธิ์, การดักจับและตรวจสอบ TLS, การป้องกันมัลแวร์ และ VPN client
    ชุดนี้ส่งผลต่อประสิทธิภาพอย่างมาก ไม่ว่าจะทำอะไรบนเครื่อง บริการเหล่านี้ก็กิน CPU และประสิทธิภาพ I/O และนักพัฒนาก็บ่นเรื่องเครื่องค้างและกระตุกแบบสุ่มมาตลอด
    เมื่อคิดถึงการเพิ่มขึ้นของแรนซัมแวร์และการขโมยทรัพย์สินทางปัญญา ก็เข้าใจว่าจำเป็นต้องมีความปลอดภัย แต่ก็สงสัยว่ามีบริษัทไหนพบวิธีที่ดีกว่าในการมอบความปลอดภัยโดยกระทบประสิทธิภาพการทำงานของนักพัฒนาน้อยลงหรือไม่

    • วิธีเดียวที่เคยเห็นคือเมื่อสถานการณ์แย่ลงก็รายงานไปยังทีม IT/ซัพพอร์ต แล้วแจ้งโฟลเดอร์และไฟล์ที่ควรถูกยกเว้น เช่น ไฟล์ชั่วคราวของบิลด์ เพื่อไม่ให้การสแกนไปขวางจนทำให้ช้าลง