เมื่อไหร่ที่ฉันควรใส่ใจเกี่ยวกับการแสดง?


16

เป็นเวลานานที่สุดในสถานที่ต่าง ๆ เช่นช่องทาง IRC ของ Java , SO และสถานที่อื่น ๆ ที่ฉันได้รับการบอกเล่าบางอย่างตามแนวของ "กังวลเกี่ยวกับลักษณะของโค้ดและการอ่าน / การทำความเข้าใจในตอนนี้และประสิทธิภาพในภายหลัง ดังนั้นเป็นเวลานานที่สุดที่ฉันไม่ได้เป็น OCD เกี่ยวกับประสิทธิภาพการทำงานสำหรับเดสก์ท็อปขนาดเล็กหรือเว็บแอปของฉันเพียงแค่ลบสิ่งที่ไม่มีประสิทธิภาพออกไปอย่างเห็นได้ชัด

คำตอบส่วนใหญ่คือ "แล้วความสามารถในการปรับขยายได้?" นั่นเป็นจุดที่ถูกต้อง แต่ถ้าแอพของฉันถูกสร้างขึ้นเพื่อแยกวิเคราะห์พูดยาว 10,000 บรรทัดไฟล์ฉันควรทำให้โค้ดของฉันยุ่งเหยิงสำหรับคนส่วนน้อยที่กำลังจะผลักไฟล์ 1,000,000 บรรทัดหรือไม่

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

คำตอบ:


23

กังวลเกี่ยวกับประสิทธิภาพเมื่อมันกลายเป็นปัญหา

หากคุณเขียนแอปขนาดเล็กเพื่อประมวลผลไฟล์ 10,000 ไฟล์และคุณได้รับไฟล์ 1,000,000 ไฟล์ทุกไฟล์ที่ 100 มันอาจไม่สำคัญว่ามันจะใช้เวลานานกว่าในการประมวลผลไฟล์หนึ่งไฟล์ อย่างไรก็ตามหากคุณได้รับไฟล์ที่มีขนาดใหญ่กว่าครั้งแรก 5-10 เท่าและแอปพลิเคชันของคุณใช้เวลาในการทำงานนานเกินไปคุณจะเริ่มสร้างโปรไฟล์และปรับให้เหมาะสม

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

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



ฉันเริ่มการทำโปรไฟล์และปรับให้เหมาะสมถ้า 1) งานใช้เวลานาน 2) หนึ่งในทรัพยากรฮาร์ดแวร์อยู่ที่สูงสุด (เช่น 100% cpu)
A. Binzxxxxxx

10

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

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

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


5
++ DICHOTOMY เท็จ! พวกเขาจะไม่เรียนรู้เหรอ? เมื่อคุณพบและแก้ไขปัญหาประสิทธิภาพการทำงานรหัสไม่ได้เป็นเพียงเร็วมันเป็นดีกว่า ฉันเสียใจที่ฉันมี แต่มีหนึ่ง upvote ให้!
Mike Dunlavey

+1 สำหรับการเขียนว่ามันเป็นขั้วคู่ที่ผิดพลาด ... ไม่เสมอไป แต่มักจะเป็น
Dan Rosenstark

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

5

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

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

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


1

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

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

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

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

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


0

ฉันพยายามทำให้โค้ดอ่านได้ - ประสิทธิภาพแย่ลง

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


0

อืม - ไม่เคยเหรอ?

ควรเขียนรหัสอย่างจริงจังเพื่อให้เข้าใจและบำรุงรักษาได้ง่าย

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

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


3
ฉันไม่เห็นด้วยกับสิ่งนี้ ข้อกำหนดด้านประสิทธิภาพเป็นข้อกำหนดที่ไม่สามารถใช้งานได้สำหรับระบบ
โธมัสโอเวนส์

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

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

0

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

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

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


0

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

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

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

ด้วย John Carmack เขาได้พูดคุยเกี่ยวกับการสาธิตเทคโนโลยีว่าต้องทำงานที่ขั้นต่ำเป็นร้อยเป็นพันเฟรมต่อวินาทีเพื่อรวมเข้ากับการผลิต นั่นไม่ใช่ความหลงใหลที่ไม่ดีต่อสุขภาพอย่างมีประสิทธิภาพ เขารู้ล่วงหน้าว่าเกมต้องวิ่งอย่างเต็มที่ที่ 30+ FPS เพื่อให้ลูกค้าพบว่ายอมรับได้ ดังนั้นหนึ่งในแง่มุมเล็ก ๆ เช่นระบบแสงเงาจึงไม่สามารถทำงานที่ 30 FPS หรือเกมอื่น ๆ อาจไม่เร็วพอที่จะให้ผลตอบรับแบบเรียลไทม์ที่ต้องการ มันใช้ไม่ได้จนกว่าจะได้ประสิทธิภาพตามที่ต้องการ ในพื้นที่ที่มีความสำคัญต่อประสิทธิภาพซึ่งมีความต้องการพื้นฐานด้านประสิทธิภาพการแก้ปัญหาที่ล้มเหลวในการบรรลุความเร็วที่เพียงพอนั้นจริง ๆ แล้วไม่ดีไปกว่าสิ่งที่ไม่ได้ผลเลย. และคุณไม่สามารถออกแบบระบบ soft shadow ที่มีประสิทธิภาพซึ่งทำงานที่หลายร้อยถึงหลายพันเฟรมต่อวินาทีตามที่จำเป็นสำหรับเอ็นจิ้นเกมเรียลไทม์เว้นแต่ว่าคุณจะใส่ความคิดที่มีประสิทธิภาพไว้ล่วงหน้า ในความเป็นจริงในกรณีเช่นนี้ 90 +% ของงานมุ่งเน้นไปที่ประสิทธิภาพเนื่องจากเป็นเรื่องเล็กน้อยที่จะเกิดขึ้นกับระบบเงาที่ทำงานได้ดีเพียง 2 ชั่วโมงต่อเฟรมโดยใช้การติดตามเส้นทาง แต่คุณไม่สามารถคาดหวังว่าจะปรับได้ เพื่อทำงานที่หลายร้อยเฟรมต่อวินาทีโดยไม่มีการเปลี่ยนแปลงวิธีการที่แตกต่างกันโดยสิ้นเชิง

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.