อธิบายความเกี่ยวข้องของความซับซ้อนเชิงซีมโทติคของการออกแบบอัลกอริทึม

ในอัลกอริทึมและความซับซ้อนเรามุ่งเน้นความซับซ้อนเชิงอัลกอริธึมนั่นคือปริมาณของทรัพยากรที่อัลกอริทึมใช้เมื่อขนาดของอินพุตเข้าสู่อนันต์

ในทางปฏิบัติสิ่งที่จำเป็นคืออัลกอริธึมที่จะทำงานได้อย่างรวดเร็วบนอินสแตนซ์จำนวน จำกัด (แม้ว่าอาจมีขนาดใหญ่มาก)

อัลกอริทึมที่ใช้งานได้ดีในทางปฏิบัติในจำนวนที่ จำกัด ของอินสแตนซ์ที่เราสนใจไม่จำเป็นต้องมีความซับซ้อนเชิงซีมโทติคที่ดี (ประสิทธิภาพที่ดีของอินสแตนซ์ที่ จำกัด จำนวนนั้น ในทำนองเดียวกันอัลกอริทึมที่มีความซับซ้อนเชิงซีมโทติคที่ดีอาจไม่สามารถใช้งานได้ดีกับจำนวนอินสแตนซ์ที่เราสนใจ (เช่นเนื่องจากค่าคงที่ขนาดใหญ่)

เหตุใดเราจึงใช้ความซับซ้อนเชิงซีมโทติค การวิเคราะห์เชิงเส้นกำกับเหล่านี้เกี่ยวข้องกับการออกแบบอัลกอริธึมในทางปฏิบัติอย่างไร

คำถามที่น่าสนใจคือ: ทางเลือกคืออะไร? อีกวิธีหนึ่งที่ฉันรู้คือการทดสอบ / การเปรียบเทียบ เราตั้งโปรแกรมอัลกอริธึมให้พวกเขาทำงานบน (ตัวอย่างที่เป็นตัวแทนของ) ชุดข้อมูล จำกัด และเปรียบเทียบผลลัพธ์ มีปัญหาสองสามข้อกับเรื่องนั้น

• ผลลัพธ์ไม่ได้เป็นแบบทั่วไปในแง่ของเครื่องจักร เรียกใช้เกณฑ์มาตรฐานของคุณบนคอมพิวเตอร์เครื่องอื่นและคุณจะได้รับผลลัพธ์ที่แตกต่างกันแน่นอนปริมาณและอาจมีคุณภาพ
• ผลลัพธ์ไม่ได้เป็นเรื่องทั่วไปในแง่ของภาษาการเขียนโปรแกรม ภาษาที่แตกต่างกันอาจทำให้เกิดผลลัพธ์ที่แตกต่างกันมาก
• ผลลัพธ์ไม่เป็นไปตามทั่วไปในแง่ของรายละเอียดการใช้งาน คุณเปรียบเทียบโปรแกรมอย่างแท้จริงไม่ใช่อัลกอริทึม การเปลี่ยนแปลงเล็กน้อยในการใช้งานอาจทำให้ประสิทธิภาพแตกต่างกันมาก
• หากกรณีที่เลวร้ายที่สุดหายากตัวอย่างอินพุตสุ่มอาจไม่มีอินสแตนซ์ที่ไม่ดี นั่นเป็นเรื่องที่ยุติธรรมถ้าคุณมีความกังวลกับประสิทธิภาพของตัวพิมพ์โดยเฉลี่ย
• ในทางปฏิบัติชุดอินพุตเปลี่ยนแปลง โดยปกติอินพุตจะใหญ่ขึ้นเมื่อเวลาผ่านไป หากคุณไม่ทำซ้ำมาตรฐานของคุณทุก ๆ หกเดือน (ใช่ข้อมูลบางส่วนจะเติบโตอย่างรวดเร็ว) ผลลัพธ์ของคุณก็ไร้ค่าทันที

ที่กล่าวว่าการเพิกเฉยเอฟเฟกต์และค่าคงที่ทุกชนิดในการวิเคราะห์เป็นเรื่องปกติ แต่สามารถเรียกว่าขี้เกียจ (ด้วยความเคารพต่อการปฏิบัติ) มันทำหน้าที่ในการเปรียบเทียบความคิดอัลกอริทึมมากกว่าที่จะระบุประสิทธิภาพของการดำเนินการที่กำหนด (แม้กระทั่ง pseudocode) เป็นที่รู้จักกันดีในชุมชนว่าสิ่งนี้เป็นสิ่งที่หยาบและการมองอย่างใกล้ชิดมักจำเป็น ตัวอย่างเช่น Quicksort มีประสิทธิภาพน้อยกว่าการจัดเรียงการแทรกสำหรับอินพุตขนาดเล็ก (มาก) เพื่อความเป็นธรรมการวิเคราะห์ที่แม่นยำยิ่งขึ้นมักเป็นเรื่องยาก ²

อีกเหตุผลหนึ่งที่ทำให้เกิดมุมมองเชิงนามธรรมอย่างเป็นทางการคือในระดับนี้สิ่งต่าง ๆ มักจะชัดเจนขึ้น ดังนั้นการศึกษาเชิงทฤษฎีมานานหลายทศวรรษได้นำเสนอแนวคิดและโครงสร้างข้อมูลที่ใช้ในทางปฏิบัติ อัลกอริธึมที่เหมาะสมที่สุดในเชิงทฤษฎีนั้นไม่ใช่สิ่งที่คุณต้องการใช้ในทางปฏิบัติเสมอไป - มีข้อควรพิจารณาอื่น ๆ คิดว่าฟีโบนัชชีกอง - และป้ายนี้อาจไม่ซ้ำกัน มันยากสำหรับโปรแกรมเมอร์ทั่วไปที่เกี่ยวข้องกับการเพิ่มประสิทธิภาพการแสดงออกทางคณิตศาสตร์จะเกิดขึ้นกับความคิดใหม่ในระดับนี้ (ไม่ได้บอกว่ามันจะไม่เกิดขึ้น); แม้ว่าเธอจะสามารถ (และควร) ทำสิ่งที่เหมาะสมที่สุดกับความคิดที่หลอมรวมได้

มีเครื่องมือทางทฤษฎีและเป็นทางการที่จะปิดช่องว่างในการฝึกในระดับหนึ่ง ตัวอย่างคือ

• พิจารณาลำดับชั้นของหน่วยความจำ (และ I / O อื่น ๆ )
• วิเคราะห์กรณีเฉลี่ย (ตามความเหมาะสม)
• การวิเคราะห์ตัวเลขของงบเดี่ยว (แทนที่จะเป็นตัววัดต้นทุนนามธรรม) และ
• การกำหนดปัจจัยคงที่

ยกตัวอย่างเช่น Knuth เป็นที่รู้จักกันอย่างแท้จริงสำหรับการนับจำนวนของข้อความที่แตกต่างกัน วิธีการนั้นเป็นไปไม่ได้ในระดับนามธรรมและยากที่จะทำในแบบจำลองที่ซับซ้อนมากขึ้น (คิดว่า Java) ดู [4] สำหรับตัวอย่างที่ทันสมัย

จะมีช่องว่างระหว่างทฤษฎีและการปฏิบัติเสมอ ขณะนี้เรากำลังทำงานกับเครื่องมือ³โดยมีเป้าหมายที่จะรวมสิ่งที่ดีที่สุดของทั้งสองโลกเข้าด้วยกันเพื่อทำนายเสียงสำหรับค่าใช้จ่ายอัลกอริทึมและรันไทม์ (โดยเฉลี่ย) แต่จนถึงตอนนี้เรายังไม่สามารถทำได้ ค่าใช้จ่าย แต่รันไทม์ที่น้อยกว่า (ในเครื่องบางเครื่อง) กว่าค่าที่เทียบเท่า (แม้ว่าเราจะสามารถตรวจจับได้และสนับสนุนการค้นหาเหตุผล)

ฉันแนะนำให้ผู้ฝึกใช้ทฤษฎีเพื่อกรองพื้นที่ของอัลกอริธึมก่อนใช้การวัดประสิทธิภาพ:

if ( input size forever bounded? ) {
  benchmark available implementations, choose best
  schedule new benchmarks for when machine changes
}
else {
  benchmark implementations of all asymptotically good algorithms
  choose the best
  schedule new benchmarks for when machine changes or inputs grow significantly
}

1. อาจมีการเปลี่ยนแปลงอย่างบ้าคลั่งในประสิทธิภาพแบบสัมบูรณ์และสัมพัทธ์เมื่อจำนวนแคชที่หายไปเพิ่มขึ้นซึ่งโดยทั่วไปจะเกิดขึ้นเมื่ออินพุตเพิ่มขึ้น แต่เครื่องยังคงเหมือนเดิม
2. ในขณะที่นักวิจัยชั้นนำในสาขาไม่สามารถทำได้
3. ค้นหาเครื่องมือที่นี่ ตัวอย่างการใช้งานได้รับการเผยแพร่ในDual Pivot Quicksort ของ Engineering Java 7 โดยใช้ MaLiJAnโดย S. Wild และคณะ (2012) [ พิมพ์ล่วงหน้า ]
4. การวิเคราะห์รายกรณีโดยเฉลี่ยของ Dual Pivot Quicksort ของ Java 7โดย S. Wild และ M. Nebel (2012) - [ preprint ]

ฉันคิดว่าคำถามนี้เกิดจากการสอนหลักสูตรซึ่งรวมถึงการวิเคราะห์เชิงเส้นกำกับ มีคำตอบที่เป็นไปได้หลายประการว่าทำไมสื่อนี้จึงสอนในชั้นเรียนเบื้องต้น:

• การวิเคราะห์เชิงเส้นกำกับเป็นสิ่งที่เป็นนามธรรมทางคณิตศาสตร์ที่ให้ผลในการวิเคราะห์ ในฐานะนักคณิตศาสตร์ (เรา) เราต้องการที่จะวิเคราะห์อัลกอริธึมและวิธีเดียวที่จะทำให้เชื่องถึงความซับซ้อนของพวกเขาคือการใช้การวิเคราะห์เชิงซีมโทติค

• การประเมินประสิทธิภาพของซีมโทติคจะชี้ให้เห็นหลักการบางอย่างที่มีประโยชน์ในทางปฏิบัติ: ตัวอย่างเช่นจดจ่อกับส่วนของรหัสที่ใช้เวลาส่วนใหญ่และลดส่วนใดส่วนหนึ่งของรหัส .

• เทคนิคการวิเคราะห์เชิงเส้นบางอย่างมีประโยชน์ ฉันหมายถึงที่นี่ส่วนใหญ่จะเรียกว่า "ทฤษฎีบทหลัก" ซึ่งในหลาย ๆ กรณีเป็นคำอธิบายที่ดีของความเป็นจริง

• นอกจากนี้ยังมีเหตุผลทางประวัติศาสตร์: เมื่อผู้คนเริ่มวิเคราะห์อัลกอริทึมเป็นครั้งแรกพวกเขาคิดอย่างจริงจังว่าความซับซ้อนของซีมโทติคสะท้อนการใช้งานจริง อย่างไรก็ตามในที่สุดพวกเขาก็พิสูจน์ผิด สิ่งเดียวกันนี้เกิดขึ้นกับ P ในชั้นเรียนของปัญหาที่แก้ไขได้อย่างมีประสิทธิภาพและปัญหา NP เป็นระดับของปัญหาที่ดื้อดึงซึ่งทั้งสองอย่างนี้ทำให้เข้าใจผิดในทางปฏิบัติ

โดยส่วนตัวแล้วฉันคิดว่าการวิเคราะห์เชิงเส้นกำกับนั้นเป็นส่วนที่สมเหตุสมผลของหลักสูตร ส่วนที่น่าสงสัยเพิ่มเติม ได้แก่ ทฤษฎีภาษาที่เป็นทางการและทฤษฎีความซับซ้อน (สิ่งใดที่เกี่ยวข้องกับเครื่องทัวริง) บางคนโต้แย้งว่าแม้ว่าอาสาสมัครเหล่านี้จะไม่เป็นประโยชน์ต่อโปรแกรมเมอร์ แต่พวกเขาก็ปลูกฝังความคิดบางอย่างที่จำเป็นสำหรับการเป็นแพทย์ที่ดี บางคนแย้งว่าทฤษฎีบางครั้งมีอิทธิพลต่อการฝึกฝนและกรณีที่หายากเหล่านี้ก็เพียงพอที่จะแสดงให้เห็นถึงการสอนวิชาที่ค่อนข้างลึกลับเหล่านี้ให้กับผู้ชมวิทยาศาสตร์คอมพิวเตอร์ทั่วไป ฉันอยากให้พวกเขาเรียนรู้ประวัติศาสตร์หรือวรรณคดีหรือวิชาอื่น ๆ ที่พวกเขาสนใจจริง ๆ ทั้งสองมีความเกี่ยวข้องกับโอกาสในการทำงานในอนาคตของพวกเขาและที่สำคัญกว่าสำหรับพวกเขาในฐานะมนุษย์

มีสองเหตุผลที่ร้ายแรงในการใช้การวิเคราะห์เชิงเวลาในการทำงาน:

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

• เพื่อให้สามารถคำนวณทางคณิตศาสตร์ได้ง่าย กรณีเช่นนี้เป็นไปได้ที่จะค้นหานิพจน์ที่แน่นอนสำหรับจำนวนการดำเนินการเป็นพิเศษ การศึกษา asymptotics ช่วยเพิ่มความเป็นไปได้มากขึ้น (เช่นการประมาณ asymptotic ของฟังก์ชั่นที่ซับซ้อนมีประโยชน์)

และยังมีอีกหลายคน (เช่นความเป็นอิสระของเครื่องจักรความหมายการเปรียบเทียบ ... )

ดังที่ระบุไว้ในคำตอบของราฟาเอลการคำนวณที่แม่นยำของเวลาทำงานที่แย่ที่สุดอาจเป็นเรื่องยากมาก การคำนวณที่แน่นอนอาจไม่จำเป็นเนื่องจากรุ่น RAM นั้นมีการประมาณไว้แล้ว ตัวอย่างเช่นการดำเนินการทั้งหมดใช้เวลาเท่ากันหรือไม่ การใช้งานเฉพาะ (ฮาร์ดแวร์การปรับให้เหมาะสม) อาจทำให้อัลกอริทึมเร็วขึ้นด้วยปัจจัยคงที่ เราต้องการเข้าใจว่าอัลกอริทึมที่มีประสิทธิภาพนั้นขึ้นอยู่กับปัจจัยเหล่านี้อย่างไร นี่คือแรงจูงใจที่ยิ่งใหญ่สำหรับการใช้การวิเคราะห์เชิงเส้นกำกับ

เพราะ asymptotics นั้น "ง่าย" (ดีกว่าง่ายกว่าการทำการวิเคราะห์ที่แน่นอนสำหรับกรณีที่ จำกัด อยู่แล้ว)

เปรียบเทียบเช่นสารานุกรม "ศิลปะแห่งการเขียนโปรแกรมคอมพิวเตอร์" โดย Knuth ซึ่งทำการวิเคราะห์รายละเอียดของอัลกอริทึมที่สำคัญทั้งหมด (และหลาย ๆ อันที่ไม่สำคัญดังนั้น) ด้วยการวิเคราะห์กฎของหัวแม่มือที่มักจะเพียงพอที่จะได้รับการประมาณเชิงซีมโทติค หรือถูกผูกไว้) ซึ่งฝึกหัดในหนังสือ "อัลกอริธึม" ส่วนใหญ่

คุณพูดถูก หากปัญหามีความสำคัญพอการวิเคราะห์แบบ Knuth (หรืออาจมีรายละเอียดน้อยกว่าเล็กน้อย) อาจได้รับการรับประกัน ในหลายกรณีคำใบ้ของความซับซ้อนเชิงซีมโทติค (อาจเฉลี่ยกับการกระจาย) ที่พอดีกับข้อมูลการทดลองก็เพียงพอแล้ว ในกรณีส่วนใหญ่ทำการจำแนกประเภทอย่างคร่าวๆของอัลกอริธึมการแข่งขันเนื่องจากรอบแรกที่มีการกำจัดวัชพืชเมื่อเปรียบเทียบกับซีมโทติคนั้นแม่นยำ และหากไม่มีคู่แข่งการได้รับข่าวร้ายของต้นทุนที่แน่นอนในรายละเอียดนาทีนั้นเป็นเพียงการทำโทษตนเองในทางจิตเวช

ที่นี่จากการวิเคราะห์เชิงเส้นกำกับฉันถือว่าเราหมายถึงพฤติกรรมของอัลกอริทึมเมื่อขนาดของอินพุตเข้าสู่อนันต์

เหตุผลที่เราใช้การวิเคราะห์เชิงเป็นเพราะ มันเป็นประโยชน์ในการทำนายพฤติกรรมของขั้นตอนวิธีการในทางปฏิบัติ การคาดการณ์ทำให้เราสามารถตัดสินใจเช่นเมื่อเรามีอัลกอริทึมที่แตกต่างกันสำหรับปัญหาที่เราควรใช้ (การมีประโยชน์ไม่ได้หมายความว่าถูกต้องเสมอ)

คำถามเดียวกันสามารถถามเกี่ยวกับรูปแบบที่เรียบง่ายของโลกแห่งความจริง ทำไมเราถึงใช้แบบจำลองทางคณิตศาสตร์ที่ง่ายขึ้นของโลกแห่งความจริง?

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

1. โดยทั่วไปแล้วจะเป็นการประมาณที่ดีพอสำหรับโลกแห่งความเป็นจริง ในทางปฏิบัติเรามักจะเห็นว่าอัลกอริทึมที่มีการวิเคราะห์เชิงซีมโทติคที่ดีกว่าทำงานได้ดีกว่าในทางปฏิบัติ มันเป็นกรณีที่อัลกอริทึมมีพฤติกรรม asymptotic ที่ดีกว่าดังนั้นถ้าอินพุตมีขนาดใหญ่พอเรามักจะสามารถพึ่งพาการวิเคราะห์เชิง asymptotic เป็นคำทำนายแรกของพฤติกรรมอัลกอริทึม ไม่ใช่ถ้าเรารู้ว่าอินพุตจะเล็ก ขึ้นอยู่กับประสิทธิภาพที่เราต้องการเราอาจต้องทำการวิเคราะห์อย่างระมัดระวังมากขึ้นเช่นหากเรามีข้อมูลเกี่ยวกับการกระจายของอินพุตอัลกอริทึมจะได้รับเราสามารถทำการวิเคราะห์อย่างระมัดระวังมากขึ้นเพื่อให้บรรลุเป้าหมายที่เรามี (เช่นรวดเร็ว 99 % ของอินพุต) ประเด็นก็คือการวิเคราะห์เชิงซีมโทติคขั้นตอนแรกเป็นจุดเริ่มต้นที่ดี ในทางปฏิบัติเราควรทำการทดสอบประสิทธิภาพ แต่จำไว้ว่ายังมีปัญหาของตัวเอง

2. มันค่อนข้างง่ายที่จะคำนวณในทางปฏิบัติ โดยทั่วไปแล้วเราสามารถคำนวณอย่างน้อยขอบเขตที่ดีเกี่ยวกับความซับซ้อนเชิงซีเอ็นเอ็นของอัลกอริทึม เพื่อความง่ายสมมติว่าเรามีอัลกอริทึมที่มีประสิทธิภาพสูงกว่าอัลกอริธึมอื่น ๆ ในทุกอินพุต วิธีที่เราสามารถรู้จะดีกว่าคนอื่น ๆ ? เราสามารถทำวิเคราะห์ asymptotic และเห็นว่าA $A$$A$$A$มีความซับซ้อนเชิงซีมที่ดีขึ้น ไม่มีสิ่งใดที่ดีไปกว่าสิ่งอื่นในทุกอินพุต จากนั้นจะยุ่งยากมากขึ้นและขึ้นอยู่กับสิ่งที่เราใส่ใจ เราสนใจเกี่ยวกับอินพุตขนาดใหญ่หรืออินพุตเล็กหรือไม่? หากเราสนใจอินพุตที่มีขนาดใหญ่ดังนั้นจึงไม่ใช่เรื่องธรรมดาที่อัลกอริทึมนั้นมีความซับซ้อนเชิงซีมโทติคที่ดีกว่า หากเราสนใจข้อมูลเพิ่มเติมเกี่ยวกับปัจจัยการผลิตเล็กน้อยการวิเคราะห์เชิงชีวติอาจไม่เป็นประโยชน์ เราควรเปรียบเทียบเวลาทำงานของอัลกอริทึมในอินพุตที่เราสนใจ ในทางปฏิบัติสำหรับงานที่ซับซ้อนที่มีความต้องการที่ซับซ้อนการวิเคราะห์เชิงซ้อนอาจไม่เป็นประโยชน์ สำหรับปัญหาพื้นฐานง่ายๆที่ตำราอัลกอริทึมครอบคลุมมันค่อนข้างมีประโยชน์

ในความซับซ้อนเชิง asymptotic สั้น ๆ นั้นค่อนข้างง่ายในการคำนวณความซับซ้อนของอัลกอริทึมจริงสำหรับงานพื้นฐานง่าย ๆ (ปัญหาในตำราเรียนอัลกอริทึม) เมื่อเราสร้างโปรแกรมที่ซับซ้อนมากขึ้นความต้องการด้านประสิทธิภาพก็เปลี่ยนไปและมีความซับซ้อนมากขึ้นและการวิเคราะห์เชิงซ้อนอาจไม่เป็นประโยชน์

เป็นการดีที่จะเปรียบเทียบการวิเคราะห์เชิงเปรียบเทียบกับวิธีการอื่นในการทำนายประสิทธิภาพของอัลกอริทึมและเปรียบเทียบกับมัน วิธีการหนึ่งที่พบบ่อยคือการทดสอบประสิทธิภาพกับอินพุตแบบสุ่มหรือเกณฑ์มาตรฐาน เป็นเรื่องปกติเมื่อคำนวณความซับซ้อนเชิงซีมโทติคนั้นยากหรือไม่สามารถทำได้เช่นเมื่อเราใช้การวิเคราะห์พฤติกรรมในการแก้ SAT อีกกรณีหนึ่งคือเมื่อข้อกำหนดมีความซับซ้อนมากขึ้นเช่นเมื่อประสิทธิภาพของโปรแกรมขึ้นอยู่กับปัจจัยภายนอกและเป้าหมายของเราอาจมีบางสิ่งบางอย่างที่เสร็จสิ้นภายใต้การ จำกัด เวลาคงที่ (เช่นคิดเกี่ยวกับการอัปเดตอินเทอร์เฟซที่แสดงต่อผู้ใช้) ปัจจัยการผลิต

แต่โปรดทราบว่าการวิเคราะห์ประสิทธิภาพยังมีปัญหาอยู่ มันไม่ได้ให้ผู้รับการคำนวณทางคณิตศาสตร์เกี่ยวกับประสิทธิภาพที่น้อยกว่าที่เราเรียกใช้การทดสอบประสิทธิภาพในอินพุตทั้งหมดที่จะได้รับกับอัลกอริทึม (มักจะคำนวณ infeasbile) (และบ่อยครั้งที่มันเป็นไปไม่ได้ที่จะตัดสินอินพุตบางส่วน ถ้าเราทดสอบกับกลุ่มตัวอย่างแบบสุ่มหรือมาตรฐานที่เรากำลังปริยายสมมติบางระเบียบ เกี่ยวกับประสิทธิภาพของอัลกอริทึมคือขั้นตอนวิธีการจะดำเนินการในทำนองเดียวกันในปัจจัยการผลิตอื่น ๆ ที่ไม่ได้เป็นส่วนหนึ่งของการทดสอบประสิทธิภาพ

ปัญหาที่สองของการทดสอบประสิทธิภาพคือขึ้นอยู่กับสภาพแวดล้อมการทดสอบ เช่นประสิทธิภาพของโปรแกรมไม่ได้พิจารณาจากอินพุตเพียงอย่างเดียว แต่ปัจจัยภายนอก (เช่นประเภทเครื่อง, ระบบปฏิบัติการ, ประสิทธิภาพของอัลกอริธึมการเข้ารหัส, การใช้ประโยชน์จาก CPU, เวลาในการเข้าถึงหน่วยความจำและอื่น ๆ ) ซึ่งบางอย่างอาจแตกต่างกัน การทดสอบบนเครื่องเดียวกัน อีกครั้งที่นี่เราสมมติว่าสภาพแวดล้อมเฉพาะที่การทดสอบประสิทธิภาพดำเนินการคล้ายกับสภาพแวดล้อมจริงยกเว้นว่าเราทำการทดสอบประสิทธิภาพในทุกสภาพแวดล้อมที่เราอาจเรียกใช้โปรแกรมบน (และเราจะทำนายได้อย่างไรว่าเครื่องที่ใครบางคนอาจเรียกใช้การเรียงลำดับ ขั้นตอนวิธีใน 10 ปี?)

เปรียบเทียบสิ่งเหล่านี้กับการคำนวณเวลาการทำงานของ asymptotic ของ MergeSort ( ) และเปรียบเทียบกับเวลาในการพูดของ SelectionSort ( ) หรือ BinarySerch ) พร้อม LinearSearch ( )Θ ( n 2 ) Θ ( lg n ) O ( n $\Theta(n \lg n)$$\Theta(n^2)$$\Theta(\lg n)$$O(n)$

$O(n^2)$$O(n \log n)$$O(n^2)$ เพื่อให้เสร็จสิ้นเมื่อเปรียบเทียบกับ quicksort

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

และความคุ้มค่าในการดูโค้ดข้างๆกัน ดูเหมือนว่า Bubbleort จะมีแนวคิดที่ง่ายกว่าและไม่ใช้การเรียกซ้ำ quicksort ไม่เข้าใจตามหลักการ pivot "ค่ามัธยฐานของ 3" ทันที Bubbleort อาจถูกนำไปใช้ในลูปโดยไม่มีรูทีนย่อยในขณะที่ quicksort อาจมีรูทีนย่อยอย่างน้อยหนึ่งตัว นี่แสดงให้เห็นถึงรูปแบบที่ความซับซ้อนของโค้ดมากขึ้นบางครั้งสามารถปรับปรุงความซับซ้อนแบบซีมโทติคได้ด้วยค่าใช้จ่ายของความเรียบง่ายของโค้ด บางครั้งมี tradoff มากคล้ายกับแนวคิดของผลตอบแทนลดลงเล็กน้อย (ต้นกำเนิดจากเศรษฐศาสตร์) ที่จำนวนมากของความซับซ้อนของรหัส [ต้องใช้เอกสารทั้งเต็ม thms และหลักฐานเพื่อพิสูจน์] เพียงซื้อการปรับปรุงเล็กน้อยในความซับซ้อนเชิงซีมโทติค สิ่งนี้จะปรากฏขึ้นเป็นตัวอย่างกับการคูณเมทริกซ์และสามารถกราฟได้