สนับสนุนช่วงเวลาที่ทุกคนสามารถลองคิดเพื่อให้ซอฟต์แวร์ทำงานได้เร็วขึ้น?

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

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

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

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

ในที่สุดควรจัดสรรเวลา "เท่าไหร่" เพื่อให้ได้ผลลัพธ์ที่ดีโดยไม่สร้างความเป็นไปได้ที่จะหยุดพัก

การทดลองจำเป็นต้องพิสูจน์ว่ามี "วิธีที่เร็วกว่าในการทำบางสิ่ง" อยู่หรือไม่? (เพิ่ม 2011-06-07)

ที่เกี่ยวข้อง:

• อะไรคือกลยุทธ์ของคุณในการพัฒนาระดับทีมของคุณอย่างฉลาด?
• การแฮ็กรหัสจะไม่ดีเมื่อใด

( เพื่อความโปรดปรานเท่านั้น -2011/06/07 ขนาดทีมคือ 2-4 นักพัฒนาไม่มี QA เฉพาะรหัสการทดสอบหน่วยและการทดสอบประสิทธิภาพที่ทำโดยนักพัฒนาเนื่องจากลักษณะของโครงการผล profiler จึงมีประโยชน์ในการแสดง เวลาดำเนินการตามสัดส่วนแม้ว่าจะไม่ได้เปิดเผยคอขวดเดียว)

ทางออกที่ดีที่สุดของคุณคือการระบุฮอตสปอตกับ profiler และ - ในฐานะทีม - หารือเกี่ยวกับวิธีการแก้ไขฮอตสปอต

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

การมีโปรแกรมเมอร์แฮ็คที่ฐานความพยายามในการทดสอบความคิดหมายความว่าคุณไม่สามารถควบคุมสิ่งที่เกิดขึ้นและทำงานได้หรือไม่

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

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

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

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

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

1. พยายามที่จะมุ่งเน้นไปที่สถานการณ์ที่สำคัญหรือเส้นทางรหัสที่สงสัยว่าคอขวด อย่าเสียเวลาในการปรับแต่งสิ่งที่ไม่จำเป็นต้องปรับให้เหมาะสม (ถ้ามันไม่พัง ... )
2. ทำให้กลุ่มเล็ก ๆ และจดจ่อกับคนที่รู้รหัสดีที่สุด อย่าลืมที่จะรวมผู้ทดสอบและผู้จัดการโปรแกรมของคุณสมบัติ - พวกเขามีข้อมูลเชิงลึกที่สำคัญและสามารถได้รับประโยชน์จากการเข้าร่วมหรือรวบรวมข้อมูลสำหรับวิธีที่พวกเขาสามารถทดสอบได้ดีขึ้น
3. เริ่มต้นเซสชันโดยให้เจ้าของพื้นที่แสดงแผนภาพระดับบล็อกสถาปัตยกรรมระดับสูงและภาพรวมของพื้นที่ อะไรคือองค์ประกอบที่สำคัญและอธิบายสั้น ๆ ว่าพวกเขาทำอะไร คุณจะประหลาดใจกี่ครั้งที่แผนภาพบล็อกไม่ได้สะท้อนความเป็นจริงเมื่อเราขุดลงในโค้ด (ข้อความอ้างอิงจริง: "ฉันไม่รู้ว่าเรายังใช้ส่วนประกอบนั้นอยู่ฉันคิดว่าเราได้กำจัดมันไปหลายปีแล้ว!")
4. คาดว่าจะพบข้อบกพร่องการทำงานเช่นเดียวกับปัญหาที่สมบูรณ์ นั่นเป็นสิ่งที่ดี นอกจากนี้คาดหวังว่าบางครั้งคุณจะไม่พบสิ่งที่สำคัญ นั่นอาจเป็นสิ่งที่ดีเช่นกัน
5. คาดว่าจะมีช่วงยาวหลายครั้ง เหล่านี้คือการประชุมการทำงาน รับความสะดวกสบายและทำงานผ่านมัน คุณจะทำอะไรได้มากขึ้นเมื่อทุกคนสามารถทำงานร่วมกันเพื่อยืดเหยียด
6. จดบันทึกโน้ตที่ดี หากคุณใช้ฐานข้อมูลการติดตามข้อบกพร่องให้พิจารณาเปิดปัญหาทันทีเพื่อติดตามแม้ว่าจะมีลำดับความสำคัญต่ำ

หลีกเลี่ยงการให้ทั้งทีมเข้าร่วมใน "Performance Push" สิ่งเหล่านี้มักไม่มีผลลัพธ์ที่ผู้บริหารคาดหวังด้วยเหตุผลที่Thorbjørn Ravn Andersen พูดถึงในคำตอบอื่น คุณจะได้รับผลตอบแทนที่ดีในบางพื้นที่การถดถอยในด้านอื่น ๆ ที่ผู้คนไม่คุ้นเคยและเป็นการยากที่จะคาดเดา / ติดตามว่าคุณควรได้รับผลกำไรมากแค่ไหนเมื่อพูดว่า "คุณทำเสร็จแล้ว" นั่นเป็นบทสนทนาที่น่าท้าทายสำหรับการจัดการ

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

... และในการทำงานมีสองขั้นตอนตามลำดับนี้:

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

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

โดยทั่วไป (**) คุณจะไม่ได้รับประสิทธิภาพที่ดีขึ้นจากการทดลอง

คุณได้รับมันโดย

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

• รู้วิธีการปรับแต่งซอฟต์แวร์โดยการหากิจกรรมที่มี a) แพงเป็นเปอร์เซ็นต์และ b) เปลี่ยนได้ด้วยสิ่งที่ดีกว่า ทุกคนรู้ว่าคุณควร "ใช้ตัวสร้างโปรไฟล์" แต่นั่นไม่เพียงพอ

ตรวจสอบคำตอบนี้กับคำถามอื่นของคุณ

** ข้อยกเว้นอาจเป็นรหัสที่ขึ้นอยู่กับฮาร์ดแวร์แน่นเช่นการเรนเดอร์กราฟิก, ตัวประมวลผลของโปรเซสเซอร์หรือพฤติกรรมของ CUDA หรือการทดลองกับเครือข่ายหรือโปรโตคอล DB ซึ่งคุณเพียงแค่ต้องคุ้นเคยกับวิธีที่ดีที่สุดในการใช้งาน

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

เพียงเพื่อให้ตัวอย่างที่เป็นรูปธรรมนี่คือโปรแกรมที่มีซอร์สโค้ด (ใน C ++) ที่ทำงานได้ มันกลั่นจากโปรแกรม C จริงที่ฉันทำงาน

มันทำในสิ่งที่ตั้งใจจะทำ แต่เวลาส่วนใดที่ไม่จำเป็นจริงๆ ? ความเร็วจะเพิ่มขึ้นเท่าไหร่

ในเวอร์ชันแรกของโปรแกรมบางสิ่งที่ดูสมเหตุสมผลและไม่เหมาะสม (ที่มองไม่เห็นกับผู้สร้างโปรไฟล์) นั้นใช้เวลา 33.3% เมื่อมันถูกแทนที่เวลานั้นจะถูกบันทึกและนั่นเป็นโปรแกรมรุ่นที่สอง

ในเวอร์ชันที่สองของโปรแกรมสิ่งอื่น (ที่มองไม่เห็นกับผู้สร้างโปรไฟล์ใด ๆ ) ที่สามารถลบออกได้คือการใช้เวลา 16.7% การลบมันนำไปสู่เวอร์ชัน 3

ในเวอร์ชัน 3 ถูกลบ 13% จากสิ่งที่เหลืออยู่ 66% ถูกลบออก จากสิ่งที่เหลืออยู่หลังจากนั้น 61% ถูกลบออก!

ในที่สุดจากสิ่งที่เหลือหลังจากนั้น 98% ถูกลบ!

ดังนั้นภาพใหญ่คืออะไร ในทุก ๆ 1000 รอบที่โปรแกรมเดิมใช้ไป 998!

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