ในยุคของการคำนวณที่ทันสมัยใน 'แอพทางธุรกิจทั่วไป' - เหตุใดประสิทธิภาพจึงมีความสำคัญ [ปิด]

นี่อาจเป็นคำถามแปลก ๆ สำหรับพวกคุณบางคน

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

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

สิ่งที่ฉันพยายามที่จะเข้าใจคือ: ทำไมเรื่องนี้?

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

แต่สำหรับแอปทางธุรกิจระดับสูงตามปกติทั่วไปทำไมประสิทธิภาพถึงสำคัญ?

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

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

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

คำถามของฉันแบ่งเป็นสองส่วน:

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

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

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

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

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

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

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

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

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

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

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

สิ่งนี้ถูกกล่าวว่าประสิทธิภาพโดยทั่วไปเป็นสิ่งสำคัญ :

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

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

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

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

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

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

ใช่แล้ว!

เมื่อคุณขอตัวอย่างสถานการณ์ในชีวิตประจำวันหลายอย่างที่คุณนึกถึง:

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

2. การตอบสนอง : มีการศึกษาการใช้งาน (ถ้าฉันมีเวลาฉันจะเพิ่มลิงก์ไปยังคำถามที่เกี่ยวข้องใน ux.se ... ) ว่าความพึงพอใจของผู้ใช้นั้นเกี่ยวข้องกับการตอบสนองเป็นอย่างมาก ความแตกต่างในเวลาตอบสนอง 200ms เทียบกับ 400ms สามารถทำให้คุณเสียค่าใช้จ่ายเป็นจำนวนมากกับลูกค้าของคุณทำให้คุณเป็นคู่แข่ง

3. ระบบฝังตัว : คอมพิวเตอร์ไม่เริ่มเร็วขึ้นช้าลงและมีขนาดเล็กลง ^ _ ^ การพัฒนาอุปกรณ์พกพามีผลกระทบอย่างมากต่อการพัฒนาแอปพลิเคชัน แน่นอนว่าเราสามารถโยนหน่วยความจำและรอบ CPU เช่น Jelly Beans บนคอมพิวเตอร์เดสก์ท็อปที่ทันสมัย ​​แต่ตอนนี้หัวหน้าของคุณขอให้คุณใช้อัลกอริทึมการวิเคราะห์การนอนหลับบนนาฬิกาประหลาดหรือซิมการ์ด ...

ในทางปฏิบัติในวันนี้การปฏิบัติงานมีความสำคัญในโปรแกรมธุรกิจปกติทั่วไปใช่หรือไม่

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

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

ในแอปพลิเคชันธุรกิจสมัยใหม่ปัญหาด้านประสิทธิภาพไม่ได้อยู่ในรูปของการขาด CPU หรือหน่วยความจำ แต่พวกเขาอยู่ในรูปแบบของเวลาแฝงเครือข่ายประสิทธิภาพ I / O และ abstractions ซ่อนสิ่งเหล่านี้ทั้งหมด ทุกอย่างขึ้นอยู่กับการออกแบบที่ดีและประสบการณ์ของนักพัฒนา แม้แต่แอปพลิเคชั่น CRUD อย่างง่าย ๆ ก็สามารถคลานไปหยุดได้ถ้ามันถูกดึงจากฐานข้อมูลทีละแถวแทนที่จะเรียกใช้คิวรี (เรียกอีกอย่างว่าปัญหา N + 1)

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

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

มันมีความสำคัญอย่างมาก

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

มีความเข้าใจผิดที่สำคัญสามประการ:

1. ส่วนใหญ่คอมพิวเตอร์ธุรกิจทั่วไปไม่ได้"เพื่อให้มีประสิทธิภาพมากขึ้น" คอมพิวเตอร์ธุรกิจทั่วไปไม่ใช่รุ่น 8-core i7 ที่มีการ์ดกราฟิก kick-ass และ RAM ขนาด 16GB มันเป็นโน้ตบุ๊กที่มีโปรเซสเซอร์มือถือระดับกลางกราฟิกแบบบูรณาการหน่วยความจำหลัก 2GB (4GB ถ้าคุณโชคดี) ดิสก์ 5400RPM และ Windows รุ่นองค์กรที่มีซอฟต์แวร์ป้องกันไวรัสและนโยบายบังคับใช้แบบเรียลไทม์ที่ทำงานอยู่ใน พื้นหลัง. หรือสำหรับที่ปรึกษาส่วนใหญ่ "คอมพิวเตอร์" เป็นเพียง iPhone ...
2. "ผู้ใช้ทางธุรกิจทั่วไป" ส่วนใหญ่ไม่ใช่ช่างเทคนิคพวกเขาไม่เข้าใจความหมายของการสร้างสเปรดชีตที่มีแท็บอ้างอิงข้าม 10-12 คอลัมน์ 150 คอลัมน์และ 30,000 แถว (ตัวเลขเหล่านี้ไม่เหมือนจริงอย่างที่คุณคิด!) และพวกเขา ไม่ต้องการที่จะรู้เช่นกัน พวกเขาจะทำมัน
3. การสูญเสียครั้งที่สองไม่เสียค่าใช้จ่ายเป็นข้อสมมติฐานที่ผิดอย่างโจ๋งครึ่ม

ภรรยาของฉันทำงานที่ปลายบนของ "สภาพแวดล้อมทางธุรกิจทั่วไป" คอมพิวเตอร์ที่เธอใช้มีค่าใช้จ่ายประมาณ 3.5 ชั่วโมงของเวลาทำงานของเธอนั้นคุ้มค่า การเริ่มต้น Microsoft Outlook ใช้เวลา - ในวันที่ดี - ประมาณ 3 นาทีจนกว่าจะพร้อม (6-8 นาทีเมื่อสิ้นไตรมาสเมื่อเซิร์ฟเวอร์มีภาระมาก) สเปรดชีต 30k แถวบางส่วนที่กล่าวถึงใช้เวลา 2-3 วินาทีในการอัปเดตค่าระหว่างที่คอมพิวเตอร์ "ค้าง" (ไม่ต้องพูดถึงระยะเวลาที่ Excel ใช้ในการเริ่มต้นและเปิดในตอนแรก!) มันยิ่งเลวร้ายลงเมื่อแชร์เดสก์ท็อป อย่าแม้แต่จะทำให้ฉันไปบน SAP
แน่นอนว่าเป็นเรื่องสำคัญที่คนหลายแสนคนสูญเสีย 20-25 นาทีต่อวันทำงานโดยไม่รออะไรเลย นั่นคือล้านหายไปซึ่งคุณสามารถทำได้แทนที่จะจ่ายเป็นเงินปันผล (หรือจ่ายค่าแรงที่สูงขึ้น)
แน่นอนว่าส่วนใหญ่ของพนักงานที่อยู่บนปลายล่างของ PayScale แต่แม้ในระดับล่างสุดเวลาคือเงิน

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

คุณดูถูกดูแคลนว่า N ^ 2 เติบโตเร็วเพียงใด สมมติว่าเรามีคอมพิวเตอร์และอัลกอริทึม N ^ 2 ของเราใช้เวลา 10 วินาทีเมื่อ N = 10 เวลาผ่านไปตอนนี้เรามีโปรเซสเซอร์ใหม่ที่เร็วกว่าเดิม 6 เท่าดังนั้นการคำนวณ 10 วินาทีของเราจึงน้อยกว่าสองวินาที N สามารถมีขนาดใหญ่ขึ้นและยังคงพอดีกับเวลารันไทม์ของต้นฉบับ 10 วินาทีได้หรือไม่ ตอนนี้เราสามารถจัดการ 24 รายการน้อยกว่าสองเท่า ระบบของเราจะเร็วขึ้นเท่าไหร่ที่จะต้องจัดการกับไอเท็มได้มากถึง 10 เท่า? มันจะต้องเร็วขึ้น 100 เท่า ข้อมูลเติบโตได้อย่างรวดเร็วและมากกว่าเช็ดความคืบหน้าของฮาร์ดแวร์คอมพิวเตอร์สำหรับอัลกอริทึม N ^ 2

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

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

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

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

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

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

ขั้นตอนวิธีการปรับปรุงการชี้แจงที่แต่ละปรับปรุงใหม่เข้ายาวเป็นสองเท่าในการคำนวณเป็นหนึ่งก่อนหน้า ( ) เมื่อรายการได้รับการอัปเดต 40 รายการ (* ยาว ) รายการจะใช้เวลาสูงสุด 15 นาทีในการทำงานอย่างเต็มประสิทธิภาพเพื่อตรวจสอบการอัปเดต สิ่งนี้ล็อคเครื่อง XP หลายเครื่องได้อย่างมีประสิทธิภาพระหว่างการอัพเดต ที่แย่กว่านั้นคือเมื่อใดก็ตามที่จะไปติดตั้งการอัปเดตอัลกอริทึมจะทำงานอีกครั้งโดยใช้เวลาอีก 15 นาที เนื่องจากเครื่องจำนวนมากมีการตั้งค่า Automatic Updates ซึ่งสามารถล็อคเครื่องเป็นเวลา 15 นาทีในการบู๊ตทุกครั้งและอาจเกิดขึ้นอีกครั้งในช่วงเวลาหนึ่งO(n) = 2n

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

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

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

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

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

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

ณ จุดนั้นการใช้ Java / Haskell / C ++ กลายเป็นการตัดสินใจออกแบบอีกครั้ง การกระทืบตัวเลขสามารถทำได้ผ่าน OpenCL บน GPU ของคุณ ส่วนต่อประสานผู้ใช้ต้องการอัลกอริธึมเวลาคงที่ เอาต์พุตและโมดูลย่อยนั้นมีความสำคัญมากกว่าการจัดคลาสของคุณเพื่อการใช้งานแคชที่ดีขึ้น 20% การมัลติเธรดกลายเป็นสิ่งสำคัญเนื่องจากผู้คนไม่ต้องการแอพที่รวดเร็วพวกเขาต้องการแอปตอบสนอง สิ่งที่ไม่สำคัญคือแอปของคุณจะช้าลงอย่างต่อเนื่อง 10% แม้แต่ 50% ก็ใช้ได้ (แต่ผู้คนเริ่มถามคำถาม) มุ่งเน้นไปที่ความถูกต้องการตอบสนองและแบบแยกส่วน

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

ค่อนข้างง่าย: ราคา

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

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

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

มีโรงเรียนแห่งความคิด 2 แห่งในเรื่องนี้:

1. หน่วยความจำและฮาร์ดแวร์โดยทั่วไปมีราคาถูกวันนี้ เพียงซื้อ RAM เพิ่มเพื่อให้คุณสามารถแคชได้มากขึ้น
2. ทำไมระบบการจัดการการเรียนรู้จึงต้องใช้ RAM 3+ GB ทั้งหมดก็คือมันออกแบบสอบถาม SQL, ส่งเปลี่ยนเส้นทางเพื่อเปิดหลักสูตรและประเมินความคืบหน้าของนักเรียนผ่านหลักสูตร

ข้อโต้แย้งที่สองชนะแล้วและฉันใช้เวลากว่าหนึ่งปีในการปรับการใช้หน่วยความจำของเรา

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

พวกเขาสมัครรับข้อมูลจากโรงเรียนแห่งแรกที่ฉันคิดไว้ด้านบน: โยนฮาร์ดแวร์เพิ่มเข้าไปเพราะราคาฮาร์ดแวร์นั้นถูกกว่าเงินเดือนนักพัฒนา

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

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

TL; DR

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

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

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

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

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

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