การเพิ่มประสิทธิภาพไมโครเป็นสิ่งสำคัญเมื่อการเข้ารหัส?

ฉันเพิ่งถามคำถามเกี่ยวกับกองมากเกินที่จะหาเหตุผลว่าทำไมisset () ได้เร็วกว่า strlen ()ในPHP สิ่งนี้ทำให้เกิดคำถามเกี่ยวกับความสำคัญของโค้ดที่อ่านได้และการปรับปรุงประสิทธิภาพของไมโครวินาทีในโค้ดนั้นคุ้มค่าหรือไม่

พ่อของฉันเป็นโปรแกรมเมอร์ที่เกษียณอายุราชการและฉันแสดงให้เขาเห็นคำตอบ เขามั่นใจอย่างแน่นอนว่าหาก coder ไม่ได้พิจารณาประสิทธิภาพในรหัสของพวกเขาแม้ในระดับไมโครพวกเขาไม่ใช่โปรแกรมเมอร์ที่ดี

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

ปัจจัยด้านสิ่งแวดล้อมอาจมีความสำคัญ - อินเทอร์เน็ตใช้พลังงาน 10% ของพลังงานโลก ฉันสงสัยว่าโค้ดไมโครวินาทีที่สิ้นเปลืองเพียงใดเมื่อทำซ้ำล้านล้านครั้งบนเว็บไซต์หลายล้านแห่ง

ฉันต้องการที่จะรู้คำตอบโดยเฉพาะอย่างยิ่งจากข้อเท็จจริงเกี่ยวกับการเขียนโปรแกรม

การเพิ่มประสิทธิภาพไมโครเป็นสิ่งสำคัญเมื่อการเข้ารหัส?

สรุปส่วนตัวของฉัน 25 คำตอบขอบคุณทุกคน

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

if (expensiveFunction() || counter < X)

ควรจะเป็น

if (counter < X || expensiveFunction())

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

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

ปัญหาเกี่ยวกับการปรับให้เหมาะสมขนาดเล็กคือมักจะทำโดยไม่มีแนวคิดว่าโปรแกรมใช้เวลามากกว่าที่จำเป็นจริง ๆ หรือไม่

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

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

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

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

การปรับให้เหมาะสมขนาดเล็กนั้นมีความสำคัญก็ต่อเมื่อตัวเลขนั้นบอกว่าเป็นเท่านั้น

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

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

เมื่อใดก็ตามที่ทุกคนถามเกี่ยวกับการเพิ่มประสิทธิภาพผมนึกถึงคำพูดจากไมเคิลเอลแจ็คสัน

กฎข้อแรกของการเพิ่มประสิทธิภาพโปรแกรม: อย่าทำ

กฎข้อที่สองของโครงการ Optimization (สำหรับผู้เชี่ยวชาญเท่านั้น!): อย่าทำมันเลย

^{อ้างอิงจาก Wikipedia ที่แก้ไขแล้วสำหรับภาษาอังกฤษแบบอังกฤษ * 8)}

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

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

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

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

isset()เทียบกับstrlen()ในPHP

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

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

การเพิ่มประสิทธิภาพทุกครั้งมีความเป็นไปได้ที่จะกลายเป็นต่อต้านการเพิ่มประสิทธิภาพในอนาคตดังนั้นควรพิจารณากลิ่นรหัสที่เป็นไปได้ที่จะเก็บไว้ให้น้อยที่สุด

ตัวอย่างจากประสบการณ์ส่วนตัว

เป็นตัวอย่างของการต่อต้านการปรับให้เหมาะสมฉันเคยต้องทำให้บริสุทธิ์ codebase ขนาดใหญ่ที่เต็มไปด้วยรหัสของแบบฟอร์มif x==0 z=0 else z=x*yเพราะมีคนสันนิษฐานว่าจุดลอยตัวคูณมักจะมีราคาแพงกว่าสาขา บนสถาปัตยกรรมเป้าหมายดั้งเดิมการเพิ่มประสิทธิภาพนี้ทำให้โค้ดรันลำดับความสำคัญเร็วขึ้น แต่เวลาเปลี่ยนไป

เมื่อเราลองใช้รหัสนี้กับ CPU ที่ทันสมัยกว่าซึ่งมีประสิทธิภาพในการทำงานที่แย่มาก - ข้อความเหล่านี้ทำให้เกิดการลบ ลดความซับซ้อนของทุกสายเหล่านี้ของรหัสที่จะเพียงแค่z=x*yทำโปรแกรมเรียกลำดับความสำคัญได้เร็วขึ้นในสถาปัตยกรรมใหม่ฟื้นฟูประสิทธิภาพการทำงานที่สูญเสียไปจากการต่อต้านการเพิ่มประสิทธิภาพ

ปัญหาที่เราต้องปรับให้เหมาะสมสำหรับวันนี้นั้นแตกต่างจากปัญหาที่เราเคยทำเพื่อปรับให้เหมาะสมสำหรับ 20 หรือ 10 ปีก่อน

จากนั้นเรากังวลเกี่ยวกับการทำงานมากที่สุดต่อรอบนาฬิกาตอนนี้เรามีแนวโน้มที่จะกังวลเกี่ยวกับไปป์ไลน์ไปป์ไลน์ mispredictions สาขาและแคชคิดถึงที่ระดับ CPU แต่การล็อคและการสื่อสารระหว่างกระบวนการมีความสำคัญมากขึ้นเมื่อเราย้ายไปหลาย สถาปัตยกรรมกระบวนการและโปรเซสเซอร์หลายตัว กระดาษของ Drepperสามารถช่วยแก้ไขปัญหาเหล่านี้ได้เป็นอย่างดี

1. เขียนโค้ดที่สะอาดกระชับเรียบง่ายและอธิบายตนเอง
2. ทำการทดสอบประสิทธิภาพเพื่อระบุปัญหาคอขวด
3. เพิ่มประสิทธิภาพส่วนที่สำคัญ

ตามกฎง่ายๆ: 95% ของรหัสของคุณทำงาน 5% ของเวลา ไม่มีจุดในการปรับให้เหมาะสมก่อนที่คุณจะโพรไฟล์ / การวัดประสิทธิภาพโค้ดของคุณและดูว่าอะไรคือ 5% ที่รัน 95% ของเวลา

คนงี่เง่าทุกคนสามารถทำ micro-optimization และคอมไพเลอร์ / รันไทม์ที่เหมาะสมจะทำสิ่งนี้ให้คุณ
การเพิ่มประสิทธิภาพรหัสที่ดีนั้นเป็นเรื่องเล็กน้อย การเขียนโค้ดที่ได้รับการปรับปรุงและพยายามทำให้ดีหลังจากนั้นน่าเบื่อที่สุดและไม่ยั่งยืนที่สุด

หากคุณจริงจังกับประสิทธิภาพการทำงานอย่าใช้ PHP สำหรับโค้ดที่มีประสิทธิภาพ ค้นหาคอขวดและเขียนใหม่ด้วยส่วนขยาย C แม้แต่การทำให้โค้ด PHP ของคุณมีขนาดเล็กที่สุดเกินกว่าที่จะทำให้งงงวยจะไม่ทำให้คุณได้ความเร็วเท่าที่ควร

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

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

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

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

ความจริงอีกอย่างหนึ่งก็คือผู้คนต้องการนำรหัสมาใช้ซ้ำและในที่สุดมันก็อาจจะแตกต่างจากตอนที่คุณเขียนมัน ทันใดนั้นผู้คนอาจสนใจ

ตัวอย่างเช่นสมมติว่าคุณเขียนสิ่งที่ชอบAngry Birdsบนพีซีหรือสำหรับคอนโซลเกม คุณไม่สนใจการเพิ่มประสิทธิภาพในระบบฟิสิกส์และระบบกราฟิกของคุณ - เนื่องจาก 2.5 GHz dual cores นั้นเป็นขั้นต่ำในทุกวันนี้และเกมของคุณทำงานได้ดีพอ จากนั้นสมาร์ทโฟนจะเข้ามาและคุณต้องการพอร์ต โอ้แกนARM 600 MHz หรือไม่

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

เช่นเดียวกับคุณพ่อของคุณกล่าวว่าอย่างน้อยคุณจะต้องพิจารณามัน คนส่วนใหญ่ไม่รู้ด้วยซ้ำว่าประสิทธิภาพการทำงานอยู่บนโต๊ะมากเพียงใดและทำการปัดมันด้วยการพูดสั้น ๆ เกี่ยวกับ "การเพิ่มประสิทธิภาพก่อนวัยอันควร" และ "ไม่ต้องทำ" นี่ไม่ใช่โปรแกรมเมอร์ที่ดี

นี่ไม่ใช่ความเห็นยอดนิยมในเว็บไซต์เหล่านี้ ลาก่อนคะแนนชื่อเสียง ....

ก่อนอื่นเราขอนำกรณีของคุณ: PHP

• ฉันไม่คิดว่า PHP เป็นภาษาชนิดหนึ่ง (ทั้งเนื่องจากลักษณะและโดเมนหลักของแอปพลิเคชัน) ที่คุณต้องกังวลเกี่ยวกับ "การเพิ่มประสิทธิภาพขนาดเล็ก" เหล่านี้ โค้ด PHP นั้นได้รับการปรับให้เหมาะสมที่สุดกับการแคช opcode
• โปรแกรมที่เขียนใน PHP ไม่ได้เป็น CPU แต่ส่วนใหญ่จะเป็นI / Oดังนั้นการเพิ่มประสิทธิภาพเหล่านี้จะไม่คุ้มค่ากับเวลาของคุณ
• สิ่งใดที่คุณต้องปรับให้เหมาะสมอาจจะติดอยู่ใน C extension และโหลดแบบไดนามิกใน PHP runtime
• อย่างที่คุณเห็นเราไม่ได้รับแรงจูงใจจากการเพิ่มประสิทธิภาพโค้ดของเราใน PHP - ในทางกลับกันถ้าคุณใช้เวลาในการทำให้โค้ด PHP อ่านง่ายขึ้นและบำรุงรักษาได้ดีขึ้น - ซึ่งจะจ่ายเงินปันผลให้คุณมากขึ้น

โดยทั่วไปแล้ว

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

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

ดังนั้นเพื่อตอบคำถามเดิมของคุณ - "การเพิ่มประสิทธิภาพขนาดเล็กมีความสำคัญเมื่อเข้ารหัสหรือไม่" - คำตอบคือ - มันขึ้นอยู่กับ -

• คุณกำลังทำสิ่งใด: โดเมนแอปพลิเคชันความซับซ้อน
• การปรับปรุงความเร็วในระดับไมโครวินาทีนั้นสำคัญมากสำหรับโปรแกรมของคุณหรือไม่?
• การเพิ่มประสิทธิภาพแบบใดที่จะได้ประโยชน์มากที่สุด อาจไม่ใช่การปรับรหัสให้เหมาะสมเสมอไป แต่เป็นสิ่งภายนอก
• "ความดี" เท่าไหร่ (ในแง่ของความเร็ว) คุณกำลังเก็บเกี่ยวเวลาที่คุณลงทุนในการเพิ่มประสิทธิภาพแบบไมโคร?
• สามารถทำได้ดีกว่าความเร็วในวิธีอื่น ๆ - โดยการเปลี่ยนฮาร์ดแวร์ RAM & ตัวประมวลผลการรันโค้ดแบบคู่ขนานหรือบนระบบแบบกระจาย?

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

ดูเหมือนจะมีคำตอบมากมายที่บอกว่าการเพิ่มประสิทธิภาพขนาดเล็กคือ

ทั้งหมดเกี่ยวกับการแลกเปลี่ยน - ประสิทธิภาพ, เวลา, ค่าใช้จ่าย, ความพยายาม, ความสามารถในการอ่าน / บำรุงรักษาและอื่น ๆ

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

if (counter < X && shouldDoThis()) // shouldDoThis() is an expensive function

ดีกว่าเสมอ

if (shouldDoThis() && counter < X ) 

มีหลายวิธีที่จะ "เพิ่มความเร็ว" รหัสของคุณแบบนั้นและความแตกต่างนั้นเล็กน้อยมาก (ไม่เสมอไป) แต่ฉันรู้สึกดีขึ้นถ้าฉันเขียนมันแบบนั้น

ฉันไม่รู้ว่าใครคิดว่านี่เป็นการเพิ่มประสิทธิภาพจริงหรือไม่ แต่ฉันคิดว่าโปรแกรมเมอร์ควรรู้และพิจารณาสิ่งเหล่านี้เมื่อเขียนรหัส

ในช่วงต้นอาชีพของฉันข้อความที่ครอบคลุมเช่น "อย่าเพิ่มประสิทธิภาพไมโคร" ทำให้เกิดความสับสนมาก ทุกอย่างเป็นสถานการณ์ ดังนั้นเหตุผลที่ผู้คนพูดว่า "วิธีปฏิบัติที่ดีที่สุด" มากกว่า "ทำสิ่งนี้"

"แนวปฏิบัติที่ดีที่สุด" เป็นตัวเลือกอันดับต้น ๆ ที่พิจารณาทุกสถานการณ์ ตัวอย่างเช่นLINQและEntity Frameworkควรใช้แทน inline SQL ที่ บริษัท ของฉันเราอยู่ในSQL Server 2000 SQL Server 2000 ไม่รองรับ Entity Framework แนวทางปฏิบัติที่ดีที่สุดต้องการ:

• การขายเจ้านายของฉันในความคิดที่จะซื้อ SQL Server รุ่นใหม่ซึ่งหมายถึงเงินหลายพันเหรียญ
• ขายนักพัฒนาบนแนวคิดของการเรียนรู้เทคโนโลยีใหม่

ฉันรู้จากประสบการณ์ว่าสิ่งนี้จะไม่เกิดขึ้น ดังนั้นฉันสามารถเลิกความเครียดไม่สิ้นสุดหรือไม่ปฏิบัติตามแนวปฏิบัติที่ดีที่สุด

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

" สำหรับทุกสิ่งที่มีฤดูกาลคือเวลาสำหรับทุกกิจกรรมภายใต้สวรรค์ "

นี่เป็นการแลกเปลี่ยนกันเสมอ

ประการแรกอุตสาหกรรมคอมพิวเตอร์เกี่ยวกับเงินในตอนท้าย สิ่งที่คุณต้องทำในฐานะนักพัฒนาคือการสร้างคุณค่าให้กับลูกค้าเพื่อให้คุณได้รับเงิน (นั่นคือการทำให้ใหญ่เกินไป แต่ประเด็นหลักอยู่ที่นี่)

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

ในบางกรณีการปรับให้เหมาะสมแบบไมโครอาจมีความสำคัญ แต่โดยทั่วไปแล้วจะเกี่ยวข้องกับรหัสที่อ่านได้น้อยกว่าหรือโค้ดที่ขยายได้น้อยกว่า (นี่ไม่ใช่กรณีตัวอย่างที่เชื่อมโยงของคุณ แต่โดยทั่วไปแล้วคือ) นี้จะเสียค่าใช้จ่ายในเวลาที่นักพัฒนาของจุด เวลานี้มีราคาแพงกว่ากำลังของเครื่องจักรนี่คือขยะ

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

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

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

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

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

ประสิทธิภาพเป็นคุณสมบัติ

บทความของ Jeff Atwood เป็นบทความที่ยอดเยี่ยมในการสร้างเว็บไซต์ที่มีประสิทธิภาพสูงและความสำคัญของการทำเช่นนั้น ...

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

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

เวลาของนักพัฒนามีค่าใช้จ่ายมากกว่าเวลาของคอมพิวเตอร์ นั่นคือสิ่งที่คุณต้องการเพิ่มประสิทธิภาพ แต่:

• มีความแตกต่างระหว่างการเพิ่มประสิทธิภาพขนาดเล็กและความซับซ้อนของอัลกอริทึม ใช้เวลามากพอที่จะมั่นใจได้ว่าคุณกำลังใช้สิทธิขั้นตอนวิธีการ
• ให้แน่ใจว่าคุณถามคำถามที่เหมาะสมไม่ได้เป็นสิ่งเดียวกับ select (select count(*) from foo) >= 1select exists(select 1 from foo)
• สำนวนภาษาบางภาษานั้นเป็นที่นิยมเพราะมันเร็วกว่ามันโอเคที่จะใช้เพราะผู้ใช้ส่วนใหญ่ของภาษาจะคุ้นเคยกับพวกเขา (ตัวอย่างของคุณเป็นตัวอย่างที่ดี)

คุณต้องการเพิ่มประสิทธิภาพอะไร

• ประสิทธิภาพของซอฟต์แวร์?
• ความน่าเชื่อถือ?
• ผลผลิตโปรแกรมเมอร์?
• ความพึงพอใจของลูกค้า?
• พลังงานอย่างมีประสิทธิภาพ?
• การบำรุงรักษา?
• เวลาไปตลาด?
• ค่าใช้จ่าย?

"เพิ่มประสิทธิภาพ" ไม่ได้หมายความว่าการทำให้โค้ดทำงานเร็วที่สุดเท่าที่จะทำได้ มีบางครั้งที่การค้นหาวิธีที่เร็วที่สุดที่จะทำสิ่งที่สำคัญ แต่นั่นไม่ใช่สิ่งที่พบได้ทั่วไปในรหัสส่วนใหญ่ หากผู้ใช้ไม่สามารถสังเกตเห็นความแตกต่างระหว่าง 50 และ 100 microseconds จะไม่มีความแตกต่างระหว่างรหัสทั้งสองในโค้ดที่จะทำงานเป็นครั้งคราวเท่านั้น นี่คือตัวอย่าง:

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

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

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

ไม่สำคัญที่จะต้องปรับขนาดให้เล็กสุดขณะเขียนโค้ด การปรับให้เหมาะสมควรทำด้วยความช่วยเหลือของผู้สร้างโปรไฟล์การปรับโค้ดให้เหมาะสมในที่ที่มันสำคัญ

อย่างไรก็ตามโปรแกรมเมอร์ควรพยายามหลีกเลี่ยงการทำสิ่งที่ชัดเจนในขณะที่เขียนโค้ด

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

สิ่งเหล่านี้ง่ายสำหรับโปรแกรมเมอร์ที่มีประสบการณ์ในการจดจำและปรับปรุงคุณภาพของรหัสเกือบตลอดเวลา

เมื่อตัดสินใจว่าจะเพิ่มประสิทธิภาพการจำไว้เสมอว่ากฎหมายของดาห์ล ดูลิงค์สำหรับคณิตศาสตร์ที่แม่นยำ; คำสั่งแหลมคมที่ต้องจำคือ:

หากส่วนหนึ่งของโปรแกรมของคุณคิดเป็น 10% ของเวลารันไทม์และคุณปรับแต่งส่วนนั้นให้ทำงานเร็วขึ้นสองเท่าโปรแกรมโดยรวมจะเร็วขึ้น 5% เท่านั้น

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

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

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

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

หากคุณได้รับการร้องเรียนจากผู้ใช้เกี่ยวกับรหัสช้าจริง ๆ แล้วพวกเขาอาจจะมีมูลค่าการพิจารณา แต่ถ้าทุกอย่างอื่นได้รับการแก้ไขคือ:

• รหัสนี้เขียนได้ดีหรือไม่?
• แอปพลิเคชันสามารถเข้าถึงข้อมูลได้โดยไม่มีปัญหาหรือไม่
• อัลกอริทึมที่ดีกว่าสามารถใช้งานได้หรือไม่?

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

ความเร็วในการเรียกใช้งานเป็นหนึ่งในหลาย ๆ ปัจจัยที่ส่งผลต่อคุณภาพของโปรแกรม บ่อยครั้งที่ความเร็วมีความสัมพันธ์แบบผกผันกับความสามารถในการอ่าน / บำรุงรักษา ในเกือบทุกกรณีรหัสจะต้องเป็นมนุษย์สามารถอ่านได้เพื่อให้รหัสสามารถรักษาได้ ครั้งเดียวที่ความสามารถในการอ่านลดลงคือเมื่อความต้องการด้านความเร็วเป็นสิ่งจำเป็น ความต้องการในการสร้างรหัสได้เร็วกว่าความสามารถในการอ่าน / บำรุงรักษาเต็มรูปแบบนั้นแทบจะไม่เคยมีมาก่อน แต่ก็มีบางกรณีที่จะเกิดขึ้น สิ่งสำคัญที่ต้องจำคือรหัสที่ปรับให้เล็กที่สุดมักจะเป็นรหัสแฮ็กดังนั้นถ้ามีข้อกำหนดที่กำหนดไว้ที่ไหนสักแห่งมันเป็นวิธีที่ผิดในการแก้ไขปัญหา ตัวอย่างเช่นผู้ใช้แทบจะไม่สังเกตเห็นความแตกต่างระหว่าง 0.5 วินาทีและ 1 วินาทีในการดำเนินการ CRUD ดังนั้นคุณไม่จำเป็นต้องเข้าไปในแอสเซมบลี - อินเตอร์ - แฮ็กเฟสต์เพื่อไปที่ 0.5 วินาที ใช่ฉันสามารถบินเฮลิคอปเตอร์เพื่อทำงานได้และมันจะเร็วเป็น 10 เท่า แต่ฉันไม่ได้เพราะราคาและความจริงที่ว่าเฮลิคอปเตอร์บินได้ยากกว่ามากเมื่อคุณเพิ่มโค้ดขนาดเล็กโดยไม่จำเป็นสิ่งนี้คือสิ่งที่คุณกำลังทำอยู่: เพิ่มความซับซ้อนและต้นทุนที่ไม่จำเป็นเพื่อบรรลุเป้าหมายที่ไม่จำเป็น

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

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

โปรดทราบว่าในปัจจุบันระบบ "ฝังตัว" ขนาดเล็กนั้นค่อนข้างใกล้เคียงกับVaxenหรือPDP-11sของปีกลายดังนั้นปัญหาเหล่านี้มักจะเกิดขึ้นบ่อยขึ้น ในระบบที่ใช้งานทั่วไปที่ทันสมัยซึ่งใช้คอมพิวเตอร์เชิงพาณิชย์ที่ทันสมัยการเพิ่มประสิทธิภาพแบบไมโครนั้นหายาก นี่อาจเป็นสาเหตุส่วนหนึ่งที่ทำให้พ่อของคุณรับตำแหน่งที่เขาทำ

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

นี่คือตัวอย่างจากคำถามที่ผ่านมาผมตอบในกองมากเกินสำหรับกรณีที่ไมโครเพิ่มประสิทธิภาพเป็นสิ่งจำเป็น: เปิดแหล่งที่มาเข้ารหัสวิดีโอสำหรับระบบฝังตัว

ปัญหาที่ยิ่งใหญ่ที่สุดของการเพิ่มประสิทธิภาพขนาดเล็กคือมันทำให้คุณเขียนรหัสได้ยากขึ้น

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

การเพิ่มประสิทธิภาพขนาดเล็กจำนวนมากจะใช้เวลาคุณต่อสู้กับสิ่งที่ไม่สำคัญ

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

ฉันไม่ได้บอกว่าการไม่ทำ micro-optimization เป็นข้อแก้ตัวในการเขียนโค้ดโง่ ๆ

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

ปัจจัยด้านสิ่งแวดล้อมเป็นปัญหาที่นี่เซิร์ฟเวอร์เหล่านั้นทำงานตลอด 24/7 และหากพวกเขาดำเนินการบางสิ่งบางอย่างจริง ๆ ก็จะสำคัญก็ต่อเมื่อมันเป็นงานที่ใช้เวลานานมาก

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

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

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

ฉันได้กล่าวไว้ก่อนและผมจะบอกว่าที่นี่: "การเพิ่มประสิทธิภาพก่อนกำหนดเป็นรากของความชั่วร้ายทั้งหมด" นี่ควรเป็นหนึ่งในกฎที่อยู่ตรงกลางใจของโปรแกรมเมอร์

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

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

มีบางสิ่งที่คุณต้องตัดสินใจล่วงหน้าที่จะส่งผลกระทบต่อประสิทธิภาพ การตัดสินใจขั้นพื้นฐานมากเช่นภาษา / รันไทม์ที่คุณจะใช้เพื่อใช้โซลูชันนี้ สิ่งเหล่านี้จำนวนมากจะส่งผลกระทบต่อประสิทธิภาพการทำงานตามคำสั่งจำนวนมากมากกว่าการเรียกวิธีหนึ่งกับวิธีอื่น สุจริต PHP เป็นภาษาสคริปต์แล้วเป็นที่นิยมประสิทธิภาพ แต่เป็นเว็บไซต์สคริปต์น้อยมากถูกสร้างขึ้นจากล่างขึ้นบนใน C / C ++ มันเทียบเคียงกับเทคโนโลยีอื่น ๆ ที่คุณอาจเลือกจาก (Java Servlets, ASP.NET ฯลฯ )

หลังจากนั้นขนาดข้อความ I / O คือเครื่องมือจัดการประสิทธิภาพตัวต่อไปที่ใหญ่ที่สุดของคุณ การปรับให้เหมาะสมสิ่งที่คุณอ่านและเขียนลงในฮาร์ดดิสก์พอร์ตอนุกรมเครือข่ายท่อ ฯลฯ จะปรับปรุงเวลารันของโปรแกรมตามลำดับความสำคัญหลายอย่างแม้ว่าอัลกอริทึมที่อยู่เบื้องหลังการทำงานของ I / O จะมีประสิทธิภาพ หลังจากนั้นลดความซับซ้อนของ Big-O ของอัลกอริทึมแล้วถ้าคุณต้องคุณสามารถ "micro-optimization" โดยเลือกวิธีการโทรที่ไม่แพงและทำการตัดสินใจที่ลึกลับอื่น ๆ ในระดับต่ำ

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

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

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

เป็นสิ่งสำคัญหาก:

1) ชีวิตของใครบางคนขึ้นอยู่กับรหัสของคุณ ฟังก์ชั่นที่ใช้เวลา 25ms เพื่อดำเนินการในเครื่องวัดอัตราการเต้นหัวใจของใครบางคนอาจเป็นความคิดที่ไม่ดี

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

การเพิ่มประสิทธิภาพไมโครเป็นสิ่งสำคัญเมื่อการเข้ารหัส?

ไม่เนื่องจากมีแพลตฟอร์มเช่นJVMและ. NETที่มีการเขียนโค้ดสำหรับเครื่องเสมือนดังนั้นการพยายามปรับการทำงานให้เหมาะสมอาจไม่ทำงานเช่นเดียวกับสิ่งที่ดีที่สุดบนเดสก์ท็อปของนักพัฒนาไม่จำเป็นต้องเหมือนกันบนเซิร์ฟเวอร์ ดูว่าฮาร์ดแวร์ซอฟต์แวร์ระดับสูงเหล่านี้นำออกไปได้ไกลแค่ไหนสำหรับจุดอื่นที่นี่ สิ่งที่ต้องพิจารณาคือความหลากหลายของฮาร์ดแวร์ความสมจริงในการปรับแต่งรหัสสำหรับชิปเฉพาะเช่น CPU หรือ GPU เมื่อรุ่นใหม่จะออกมาในเวลาน้อยกว่าหนึ่งปี

คำถามอีกข้อที่ควรพิจารณาคือประสิทธิภาพตามที่วัดจากเมตริกใด: ความเร็วในการประมวลผล, หน่วยความจำที่ใช้ในการประมวลผล, ความเร็วในการพัฒนาคุณสมบัติใหม่, ขนาดของรหัสฐานบนเซิร์ฟเวอร์ในรูปแบบที่คอมไพล์หรือไม่คอมไพล์ .? หากมีคำถามในวงกว้างพอจะกลายเป็นคำถามเล็กน้อย แต่ฉันไม่แน่ใจว่าคุณตั้งใจจะแสดงให้กว้างเท่าไหร่ที่จะเป็นอะไรก็ได้ตราบใดที่สามารถวัดได้ในบางด้าน

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

ฉันคิดว่ามีความแตกต่างอย่างมากระหว่างการวางโปรแกรมที่ดีและการเพิ่มประสิทธิภาพขนาดเล็ก

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

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

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

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

การอ่านรหัส IMHO มีความสำคัญมากกว่าการปรับให้เหมาะสมขนาดเล็กเพราะในกรณีส่วนใหญ่การปรับให้เหมาะสมขนาดเล็กนั้นไม่คุ้มค่า

บทความเกี่ยวกับการปรับให้เหมาะสมแบบไม่รู้สึกไมโคร :

ในฐานะส่วนใหญ่ของเราฉันรู้สึกเหนื่อยที่จะอ่านโพสต์บล็อกเกี่ยวกับการปรับให้เหมาะสมแบบไม่ใช้ความรู้สึกเช่นการเปลี่ยนการพิมพ์ด้วย echo, ++ $ i โดย $ i ++ หรือเครื่องหมายคำพูดคู่ด้วยเครื่องหมายคำพูดเดี่ยว ทำไม? เนื่องจากเวลา 99.999999% นั้นไม่เกี่ยวข้อง ทำไม? เนื่องจาก 99.99% ของเวลาคุณควรติดตั้งตัวเร่ง PHP เช่น APC หรือเพิ่มดัชนีที่ขาดหายไปเหล่านี้ในคอลัมน์ฐานข้อมูลของคุณหรือพยายามหลีกเลี่ยงคำขอฐานข้อมูล 1,000 รายการที่คุณมีในหน้าแรก

print ใช้ opcode มากกว่าหนึ่งอันเพราะจริง ๆ แล้วคืนบางสิ่งบางอย่าง เราสามารถสรุปได้ว่าเสียงสะท้อนนั้นเร็วกว่าการพิมพ์ แต่หนึ่งรหัสไม่มีค่าใช้จ่ายไม่มีอะไรจริงๆ

ฉันได้ลองติดตั้ง WordPress ใหม่แล้ว สคริปต์หยุดทำงานก่อนที่จะจบลงด้วย "ข้อผิดพลาดของรถบัส" บนแล็ปท็อปของฉัน แต่จำนวน opcodes นั้นมากกว่า 2.3 ล้านแล้ว พูดพอแล้ว.

ดังนั้นในกรณีส่วนใหญ่การเพิ่มประสิทธิภาพขนาดเล็กจะช่วยประหยัด 1 การดำเนินงานในล้านคน แต่ทำให้การอ่านแย่ลง

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

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

ฉันจะย้ำจุดที่ผู้อื่นทำที่นี่เพื่อประโยชน์ของทั้งการเพิ่มประสิทธิภาพที่ดีและไม่ดี:

1. การอ้างอิงถึงปัญหาที่เฉพาะเจาะจงของคุณสามารถเปลี่ยนแปลงได้และเวลาที่ใช้ในการปรับให้เหมาะสมก่อนที่จะทำส่วนโลจิคัลของแอ็พพลิเคชันของคุณเสร็จสิ้นจะเป็นการเสียเวลา ฉันหมายถึงการปรับให้เหมาะสมในระยะแรก วันนี้คุณมีList<T>และตามเวลาที่แอพของคุณจัดส่งคุณต้องเปลี่ยนเป็นLinkedList<T>และตอนนี้การเปรียบเทียบทั้งหมดทำให้เสียเวลาและความพยายาม

2. ส่วนใหญ่คอขวดที่แท้จริงของแอปพลิเคชันของคุณ (อ่านเป็นความแตกต่างที่วัดได้) อาจเป็น 5% ของรหัสของคุณ (ส่วนใหญ่จะเป็น sql) และการเพิ่มประสิทธิภาพ 95% อื่น ๆ ไม่ได้ให้ประโยชน์กับลูกค้าของคุณ

3. โดยปกติแล้วโค้ดที่มีประสิทธิภาพดีกว่ามักหมายถึงความฟุ้งซ่านมากกว่าซึ่งหมายถึงโค้ดที่ผิดพลาดมากกว่าซึ่งจะหมายถึงการบำรุงรักษาที่หนักขึ้นและเวลาที่ใช้ไปมากขึ้นซึ่งหมายความว่าคุณจะได้รับเงินน้อยลง

4. รอยเท้าคาร์บอนที่คุณประหยัดไปทั้งโลกผ่านการเพิ่มประสิทธิภาพ 1% นั้นถูกปล่อยออกมาอย่างง่ายดายโดยก๊าซเรือนกระจกที่ทีมของคุณจะต้องปล่อยออกมาในการดีบั๊กและการบำรุงรักษารหัสนั้น

ข้อเสียของการเพิ่มประสิทธิภาพที่ไม่ดีโดยเฉพาะคือ:

1. ไม่ได้ให้ประสิทธิภาพตามที่คุณคาดหวัง ดูคำถามนี้ในดังนั้นที่เพิ่มประสิทธิภาพได้ไปผิด ในความเป็นจริงมันสามารถมีผลกระทบ นั่นเป็นปัญหาของพฤติกรรมที่ไม่มีเอกสาร

2. คอมไพเลอร์สมัยใหม่ส่วนใหญ่จะทำเพื่อคุณต่อไป

ฉันจะยกตัวอย่างบางส่วนของการเพิ่มประสิทธิภาพที่ไม่ดีและดี:

เลว -

1. Int32ใช้ชนิดจำนวนเต็มขนาดเล็กแทน

2. ++i ใช้แทน i++

3. forแทนforeach(ที่เลวร้ายที่สุดที่ฉันเคยเห็นเอาชนะตรรกะโดยสิ้นเชิง)

4. หลีกเลี่ยงตัวแปรที่ปิดแล้ว

   string p;
   foreach (var item in collection)
       p = ...;
   

5. ใช้charแทนสตริงในระหว่างการต่อสตริงเช่น:

   string me = 'i' + "me myself"; // something along that line - causes boxing
   

ข้อดี (จาก. NET โลกควรอธิบายตนเอง) -

1. ค้นหาซ้ำ

   if (Dictionary<K, V>.TryGetValue(K, out V))
       do something with V
   

   แทน

   if (Dictionary<K, V>.ContainsKey(K))
       do something with Dictionary<K, V>[K]
   

2. โหลดทั้งหมด

   DirectoryInfo.EnumerateFiles();
   

   แทน

   DirectoryInfo.GetFiles();
   

3. หล่อสองขั้นตอน:

   s = o as string;
   if (s != null)
       proceed
   

   แทน

   if (o is string)
       s = (string)o;
   

4. หากคำสั่งซื้อไม่สำคัญ

   if (counter < X || expensiveFunction())
   

   แทน

   if (expensiveFunction() || counter < X)
   

5. มวย

   void M<T>(T o) //avoids boxing
   {
   
   }
   

   แทน

   void M(object o)
   {
   
   }
   

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

"คุ้มค่า" ต้องการบริบทเช่นการเขียนและอ่านและการบำรุงรักษาที่ง่ายกว่าเมื่อเทียบกับความรวดเร็วในการสร้างสิ่งที่ผู้ใช้ตอบสนองมากขึ้นโต้ตอบตอบสนองต้องใช้เวลาน้อยลงในการรอ

การออมเพนนีสักสองสามอย่างเพื่อซื้อโซดากระป๋องจะไม่ดีเท่าไหร่ถ้าฉันต้องเดินทางไกลเพื่อช่วยเพนนีเหล่านั้นโดยเฉพาะเมื่อฉันไม่ค่อยดื่มโซดาวันนี้ การประหยัดเพนนีไม่กี่กระป๋องต่อการซื้อโซดาหนึ่งล้านกระป๋องอาจเป็นเรื่องใหญ่

ในขณะเดียวกันประหยัดเพนนีไม่กี่คนเมื่อคนสองคนอยู่ติดกับฉันและคนหนึ่งเสนอสิ่งเดียวกันแน่นอนสำหรับเพนนีสองสามตัวที่ถูกกว่าและอีกอันไม่ได้และฉันเลือกอันที่แพงกว่าเพราะฉันชอบหมวกของพวกเขาดูดีกว่า ของการมองในแง่ร้าย

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

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

Wolfire อธิบายเทคนิคที่นี่และเขาต่อสู้กับเวลาที่ต้องการ: http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/

การนำไปใช้ของฉันมีการจัดการเพื่อให้สามารถทำเช่นนั้นเป็นมิลลิวินาทีในขณะที่เขาพยายามที่จะลดลงเหลือน้อยกว่าหนึ่งนาที:

หลังจากฉัน "micro-optimization" มันลดลงจาก 24 วินาทีถึง 25 มิลลิวินาทีนั่นคือตัวเปลี่ยนเกมในเวิร์กโฟลว์ ตอนนี้ศิลปินสามารถเปลี่ยนแท่นขุดได้แบบเรียลไทม์ที่ 30 FPS โดยไม่ต้องรอ 24 วินาทีทุกครั้งที่มีการเปลี่ยนแปลงเล็กน้อยกับอุปกรณ์ของพวกเขา และนั่นก็เปลี่ยนการออกแบบทั้งหมดของซอฟต์แวร์ของฉันเนื่องจากฉันไม่ต้องการแถบความคืบหน้าและสิ่งต่าง ๆ อีกต่อไปมันกลายเป็นแบบโต้ตอบทั้งหมด ดังนั้นนั่นอาจเป็น "การเพิ่มประสิทธิภาพขนาดเล็ก" ในแง่ที่ว่าการปรับปรุงทั้งหมดมาโดยไม่มีการปรับปรุงความซับซ้อนของอัลกอริทึม แต่มันเป็น "การเพิ่มประสิทธิภาพ mega-optimization" ที่ค่อนข้างมีผลซึ่งทำให้สิ่งที่เคยเป็นกระบวนการที่เจ็บปวดและไม่โต้ตอบ เป็นเรียลไทม์แบบโต้ตอบซึ่งเปลี่ยนวิธีการทำงานของผู้ใช้อย่างสมบูรณ์

การวัดความต้องการของผู้ใช้ปลายทางบริบท

ฉันชอบความคิดเห็นของ Robert ที่นี่จริง ๆ และบางทีฉันก็ไม่สามารถทำสิ่งที่ฉันต้องการได้:

ดี c'mon ไม่มีใครจะโต้แย้งว่าการเปลี่ยนแปลงแบบนี้ไม่ได้ "คุ้มค่า" คุณสามารถแสดงให้เห็นถึงผลประโยชน์ที่จับต้องได้; micro-optimization ที่เรียกว่าไม่สามารถทำได้หลายอย่าง

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

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

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

ฉันจะใช้วิธีนี้ - การเพิ่มประสิทธิภาพขนาดเล็กเป็นกระบวนการเพิ่มประสิทธิภาพบางอย่างที่ไม่ใช่คอขวดเลย ตัวอย่างเช่นหากโปรแกรมของคุณเรียกใช้ฟังก์ชันสองฟังก์ชั่น A และ B และ A ใช้เวลา 100 มิลลิวินาทีในการดำเนินการให้เสร็จสมบูรณ์และ B ใช้เวลา 2 ไมโครวินาทีและคุณยังคงเพิ่มประสิทธิภาพของฟังก์ชั่น B ซึ่งไม่เพียง แต่ไม่สำคัญเท่านั้น แต่การเพิ่มประสิทธิภาพฟังก์ชั่น B เรียกว่าการเพิ่มประสิทธิภาพไม่ใช่การเพิ่มประสิทธิภาพแบบไมโคร ความสำคัญของการเพิ่มประสิทธิภาพขึ้นอยู่กับ สมมติว่าคุณไม่มีอะไรให้ทำอีกแล้วโปรแกรมของคุณปราศจากข้อผิดพลาดใช่แล้วมันเป็นเรื่องสำคัญ แต่โดยทั่วไปคุณมีลำดับความสำคัญ สมมติว่าคุณต้องเพิ่ม / เขียนฟังก์ชั่น C หากคุณคิดว่าฟังก์ชั่นการเขียน C จะสร้างรายได้ให้คุณมากกว่าการทำโปรแกรมของคุณให้เร็วขึ้นโดยที่ไม่ต้องใช้ฟังก์ชั่นนั้น มิฉะนั้นติดตามฟังก์ชั่น นอกจากนี้ โปรแกรมเมอร์ที่มีประสบการณ์ซึ่งมุ่งเน้นที่ประสิทธิภาพไม่ต้องเสียเวลาในการปรับให้เหมาะสม แต่เพียงเขียนโปรแกรมที่รวดเร็ว อย่างน้อยพวกเขาก็รู้ว่าต้องใช้เครื่องมืออะไรและไม่ควรใช้เวลาหลายปีในการเพิ่มประสิทธิภาพ (อ่านไมโคร) ที่ไม่มีความหมาย