ในโลกของเครื่องมือบรรทัดคำสั่ง งานง่ายๆ อย่างการนับบรรทัดที่ไม่ซ้ำกันในไฟล์ โดยปกติแล้วถูกจัดการโดยไปป์ไลน์ Unix คลาสสิก: sort | uniq -c | sort -n วิธีการนี้ แม้จะน่าเชื่อถือ แต่สามารถช้าอย่างยิ่งเมื่อประมวลผลชุดข้อมูลขนาดใหญ่ เครื่องมือใหม่ที่พัฒนาด้วย Rust ชื่อ hist ได้ปรากฏตัวขึ้น อ้างว่ามีการปรับปรุงประสิทธิภาพอย่างมากเมื่อเทียบกับวิธีการแบบดั้งเดิมและแม้แต่ทางเลือกอื่นที่มีอยู่ ซึ่งจุดประกายการอภิปรายที่มีชีวิตชีวาในหมู่ผู้พัฒนาซอฟต์แวร์เกี่ยวกับแนวทางที่ถูกต้องในการปรับปรุงประสิทธิภาพ
ความก้าวหน้าด้านประสิทธิภาพและความลับในการนำไปใช้
ผู้พัฒนาที่อยู่เบื้องหลัง hist รายงานว่าสามารถปรับปรุงปริมาณงานได้สูงสุดถึง 25 เท่าเมื่อเทียบกับวิธีการแบบง่ายดั้งเดิมของ coreutils เมื่อประมวลผลไฟล์ FASTQ ขนาด 100 ล้านบรรทัด เครื่องมือนี้ไม่เพียงแต่เร็วกว่าท่อ Unix แบบดั้งเดิมเท่านั้น แต่ยังทำผลงานได้ดีกว่าเครื่องมือเฉพาะทางอื่นๆ เช่น cuniq, huniq และ sortuniq ในการทดสอบมาตรฐาน ส่วนผสมลับอยู่ที่ตัวเลือกการนำไปใช้ที่ชาญฉลาดหลายประการซึ่งลดภาระงานในการคำนวณ แทนที่จะเรียงลำดับชุดข้อมูลทั้งหมดตั้งแต่แรก hist ใช้ HashMap เพื่อนับการเกิดขึ้นไปพร้อมๆ กัน โดยจะเรียงลำดับเฉพาะผลลัพธ์สุดท้ายเท่านั้น วิธีการนี้ขจัดความจำเป็นในการผ่านข้อมูลหลายรอบ เครื่องมือยังใช้การจัดสรรพื้นที่แบบ arena สำหรับคีย์ที่เข้ามาและเก็บการอ้างอิงใน HashMap แทนที่จะเป็นค่าที่เป็นเจ้าของ ซึ่งลดการจัดสรรหน่วยความจำลงอย่างมีนัยสำคัญและปรับปรุงประสิทธิภาพของแคช
ผู้แสดงความคิดเห็นหนึ่งคนระบุว่า: มันไม่ได้ถูกออกแบบมาเกินความจำเป็น มันถูกออกแบบมาอย่างเหมาะสม คุณต้องการปริมาณงานมากขึ้น ชุดเครื่องมือ coreutils ไม่ได้ถูกออกแบบมาสำหรับปริมาณงานแต่ถูกออกแบบสำหรับความยืดหยุ่น
การเปรียบเทียบประสิทธิภาพ (ไฟล์ FASTQ ขนาด 100M บรรทัด)
| เครื่องมือ | เวลาเฉลี่ย | เทียบกับ hist |
|---|---|---|
| hist | 200.3 ms | 1.00x |
| cuniq | 434.3 ms | 2.17x |
| huniq | 2375.5 ms | 11.86x |
| sortuniq | 2593.2 ms | 12.95x |
| naive (coreutils) | 5409.9 ms | 27.01x |
| ClickHouse-local | 2700 ms* | ~0.2x* |
หมายเหตุ: ผลลัพธ์ของ ClickHouse มาจากการทดสอบของชุมชน ใช้วิธีการที่แตกต่างกัน
การอภิปรายเกี่ยวกับการประมวลผลแบบขนานเกิดขึ้น
การอภิปรายเกี่ยวกับประสิทธิภาพได้เปลี่ยนทิศทางที่น่าสนใจเมื่อผู้แสดงความคิดเห็นชี้ให้เห็นว่า ClickHouse-local ซึ่งเป็นเครื่องมือประมวลผลข้อมูลอเนกประสงค์ สามารถแก้ไขปัญหาเดียวกันได้เร็วยิ่งขึ้น—ทำการทดสอบมาตรฐานเสร็จในเวลาเพียง 2.7 วินาที เมื่อเทียบกับ 14 วินาทีของ hist สิ่งนี้จุดประกายการถกเถียงเกี่ยวกับสิ่งที่นับเป็นการเปรียบเทียบที่ยุติธรรม บางคนแย้งว่าการดำเนินการแบบขนานโดยค่าเริ่มต้นของ ClickHouse ทำให้ได้เปรียบอย่างไม่ยุติธรรม โดยแนะนำว่าการเปรียบเทียบแบบเธดเดียวจะมีความหมายมากกว่าสำหรับการประเมินประสิทธิภาพของอัลกอริทึม คนอื่นๆ โต้แย้งว่าการปิดการประมวลผลแบบขนานก็เหมือนกับการเอาล้อครึ่งหนึ่งออกจากรถเพื่อเปรียบเทียบกับรถจักรยานยนต์ โดยเน้นย้ำว่าการใช้ประโยชน์จากทรัพยากรฮาร์ดแวร์ที่มีอยู่เป็นแง่มุมที่ชอบธรรมของวิศวกรรมประสิทธิภาพ
การแลกเปลี่ยนกับการใช้หน่วยความจำและการประยุกต์ใช้ในโลกจริง
ในขณะที่ hist แสดงให้เห็นถึงความเร็วที่น่าประทับใจ สมาชิกในชุมชนก็ระบุการแลกเปลี่ยนที่เกี่ยวข้องได้อย่างรวดเร็ว วิธีการแบบดั้งเดิม sort | uniq แม้จะช้ากว่า แต่ใช้หน่วยความจำน้อยโดยการออกแบบ—มันสามารถจัดการข้อมูลขนาดหลายร้อยกิกะไบต์ได้อย่างมีประสิทธิภาพโดยการย้ายข้อมูลไปยังดิสก์เมื่อจำเป็น ในทางตรงกันข้าม วิธีการ HashMap ของ hist ต้องการให้เก็บบรรทัดที่ไม่ซ้ำทั้งหมดไว้ในหน่วยความจำ ซึ่งอาจกลายเป็นปัญหากับชุดข้อมูลที่มีรายการที่แตกต่างกันหลายล้านรายการ ข้อจำกัดนี้ทำให้ hist เหมาะอย่างยิ่งสำหรับสถานการณ์ที่จำนวนบรรทัดที่ไม่ซ้ำกันสามารถจัดการได้แต่จำนวนบรรทัดทั้งหมดมีขนาดใหญ่มหาศาล ผู้แสดงความคิดเห็นหลายคนได้แบ่งปันเครื่องมือเฉพาะทางของพวกเองสำหรับสถานการณ์ต่างๆ รวมถึง unic สำหรับการรักษาลำดับบรรทัดดั้งเดิมและ sketch-duplicates สำหรับการนับโดยประมาณด้วยการใช้หน่วยความจำคงที่
การแลกเปลี่ยน: แนวทางแบบดั้งเดิมเทียบกับแบบสมัยใหม่
| แนวทาง | ข้อดี | ข้อเสีย |
|---|---|---|
| sort | uniq | sort | จัดการไฟล์ขนาดใหญ่มากผ่านดิสก์ได้ มีให้ใช้งานได้ทั่วไป | ช้า ต้องประมวลผลข้อมูลหลายรอบ |
| hist (HashMap) | เร็วสำหรับข้อมูลที่ซ้ำกันมาก ประมวลผลครั้งเดียว | ใช้หน่วยความจำสูงสำหรับบรรทัดที่ไม่ซ้ำกันจำนวนมาก |
| ClickHouse | เร็วมาก จัดการรูปแบบต่างๆ ได้ | มีการพึ่งพาที่หนัก ทำงานแบบขู่ขนานโดยค่าเริ่มต้น |
| เครื่องมือเฉพาะทาง | ปรับให้เหมาะสมสำหรับกรณีการใช้งานเฉพาะ | ฟังก์ชันการทำงานจำกัด |
ปรัชญาของการสร้างเครื่องมือและการปรับปรุงประสิทธิภาพ
เหนือไปจากรายละเอียดทางเทคนิค การอภิปรายได้เปิดเผยคำถามที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับเวลาที่การปรับปรุงประสิทธิภาพมีความสมเหตุสมผล ผู้พัฒนาบางคนแบ่งปันประสบการณ์จากกระบวนการสัมภาษณ์ที่ผู้สมัครซึ่งแนะนำวิธีแก้ปัญหาโดยใช้ Python ที่สร้างขึ้นเองสำหรับปัญหาการเรียงลำดับถูกปฏิเสธเพราะทำให้เสียเวลาผู้พัฒนาไปกับการสร้างเครื่องมือที่มีอยู่แล้วขึ้นใหม่ คนอื่นๆ โต้แย้งว่าสิ่งแวดล้อมมีความสำคัญ—สำหรับไฟล์ขนาดเล็ก การใช้ความสามารถของภาษาที่มีอยู่แล้วอาจบำรุงรักษาได้ง่ายกว่าการใช้ไปป์ไลน์เชลล์ที่ซับซ้อนซึ่งขึ้นอยู่กับการนำเครื่องมือเฉพาะและค่าการตั้งค่าโลคейล การสนทนาได้เน้นยึงความตึงเครียดอย่างต่อเนื่องระหว่างการสร้างเครื่องมือเฉพาะทางที่มีประสิทธิภาพสูงกับการใช้ประโยชน์จากยูทิลิตี้อเนกประสงค์ที่มีอยู่
การปรากฏตัวของ hist เป็นตัวแทนของอะไรมากไปกว่าเครื่องมือบรรทัดคำสั่งที่เร็วอีกเครื่องหนึ่ง—มันสะท้อนถึงภูมิทัศน์ที่กำลังพัฒนาของการเขียนโปรแกรมระบบซึ่งภาษายุคใหม่อย่าง Rust ช่วยให้ผู้พัฒนาสามารถคิดใหม่เกี่ยวกับยูทิลิตี Unix คลาสสิกด้วยประสิทธิภาพในใจ แม้ว่าเครื่องมืออาจไม่แทนที่วิธีการแบบดั้งเดิมในทุกสถานการณ์ แต่มันให้ตัวเลือกที่มีค่าสำหรับเวิร์กโฟลว์ที่เน้นข้อมูลซึ่งความเร็วเป็นเรื่องสำคัญ ดังที่ผู้แสดงความคิดเห็นหนึ่งคนจับใจความแนวคิดของวิศวกรได้อย่างสมบูรณ์แบบ: การอภิปรายเกี่ยวกับข้อกำหนดเป็นไปได้ แต่นั่นไม่ได้ลบล้างว่าวิธีแก้ปัญหาที่ได้มาด้วยความพยายามที่สมเหตุสมผลนั้นตรงตามข้อกำหนดหรือไม่
อ้างอิง: hist