ควรหลีกเลี่ยง STL ในแอปพลิเคชันขนาดใหญ่หรือไม่

นี่อาจฟังดูเป็นคำถามแปลก ๆ แต่ในแผนกของฉันเรากำลังมีปัญหากับสถานการณ์ต่อไปนี้:

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

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

เห็นได้ชัดว่าเราสามารถแทนที่พารามิเตอร์อินพุต / เอาต์พุตด้วยประเภท C ++ มาตรฐานและสร้างวัตถุ STL จากสิ่งที่อยู่ภายในฟังก์ชั่น แต่สิ่งนี้อาจทำให้ประสิทธิภาพลดลง

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

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

+-----------+-----------+----
| Machine1  | Machine2  | ...
| App_Inst1 | App_Inst2 | ...
|           |           |    
| DLL1.1    | DLL2.1    | ...
| DLL1.2    | DLL2.2    | ...
| DLL1.x    | DLL2.x    | ...
+-----------+-----------+----

App_Inst1 เป็นอินสแตนซ์ของแอปพลิเคชันที่ติดตั้งบน Machine1 ในขณะที่ App_Inst2 เป็นอินสแตนซ์ของแอปพลิเคชันเดียวกันที่ติดตั้งใน Machine2
DLL1.x เป็น DLL ติดตั้งบน Machine1 ในขณะที่ DLL2.x เป็น DLL ติดตั้งบน Machine2
DLLx.1 ครอบคลุมส่งออก function1
DLLx.2 ครอบคลุม function2 ที่ส่งออก

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

พารามิเตอร์อินพุต / เอาต์พุตของ function1 และ function2 เป็นวัตถุ STL (C ++ Standard Type Library) และเป็นประจำฉันอาจคาดหวังให้ลูกค้าทำการอัปเดตของ App_Inst1, App_Inst2, DLLx.y (แต่ไม่ใช่ทั้งหมดพวกเขาอาจอัพเกรด Machine1 แต่ ไม่ใช่ Machine2 หรืออัปเกรดแอปพลิเคชันเท่านั้น แต่ไม่ใช่ DLLs หรือในทางกลับกัน, ... ) เห็นได้ชัดว่าหากอินเทอร์เฟซ (พารามิเตอร์อินพุต / เอาต์พุต) เปลี่ยนแปลงจากนั้นลูกค้าจะถูกบังคับให้ทำการอัพเกรดอย่างสมบูรณ์

อย่างไรก็ตามดังที่กล่าวไว้ใน StackOverflow URL ที่อ้างถึงการคอมไพล์ใหม่อย่างง่ายของ App_Inst1 หรือหนึ่งใน DLLs อาจทำให้ทั้งระบบล่มสลายดังนั้นชื่อเดิมของโพสต์นี้จึงไม่แนะนำการใช้ STL (เทมเพลตมาตรฐาน C ++ Library) สำหรับแอพพลิเคชั่นขนาดใหญ่

ฉันหวังว่าฉันจะลบคำถาม / ข้อสงสัยออกไป

นี่เป็นปัญหา XY คลาสสิกที่เย็นชา

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

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

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

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

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

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

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

แคชมีราคาแพงกว่า แต่มีผลกับรหัสที่ใช้งานล่าสุดเท่านั้นไม่ใช่รหัสที่อยู่ในหน่วยความจำที่ไม่ได้ใช้งาน

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

แต่: ฟังก์ชั่นที่เราใช้กำลังผ่านพารามิเตอร์อินพุตและเอาต์พุตเป็นวัตถุ STL และตามที่กล่าวไว้ใน StackOverflow URL นี้เป็นความคิดที่แย่มาก

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

ที่ซึ่งอาจเป็นปัญหาคือเมื่อไลบรารีถูกสร้างโดยบุคคลอื่นหรือสามารถอัพเดตแยกจากกัน

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

ไม่ได้จริงๆ

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

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

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

คุณไม่มีจุดประสงค์ของคำถามนั้น

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

หากคุณสร้าง DLLs จากทรีแหล่งเดียวกันในเวลาเดียวกันด้วยคอมไพเลอร์และตัวเลือกการสร้างเดียวกันมันจะทำงานได้ดี

อย่างไรก็ตาม "Windows รส" วิธีการแยกโปรแกรมลงในหลายชิ้นบางแห่งซึ่งเป็นอีกครั้งที่ใช้งานได้เป็นส่วนประกอบ COM สิ่งเหล่านี้อาจมีขนาดเล็ก (ตัวควบคุมส่วนบุคคลหรือตัวแปลงสัญญาณ) หรือขนาดใหญ่ (IE สามารถใช้ได้เป็นตัวควบคุม COM ใน mshtml.dll)

โหลดแบบไดนามิกเมื่อจำเป็นและขนถ่ายหลังจากนั้น

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

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

อาจเติบโตขนาดใหญ่ที่พีซีเครื่องเดียวไม่สามารถจัดการได้อีกต่อไป

ซื้อพีซีที่ใหญ่กว่า

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

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

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

ส่วนแรกนั้นสมเหตุสมผล (การแยกแอปพลิเคชันไปยังเครื่องต่างๆด้วยเหตุผลด้านประสิทธิภาพ)

ส่วนที่สอง (การโหลดและการยกเลิกการโหลดไลบรารี) ไม่สมเหตุสมผลเนื่องจากเป็นความพยายามพิเศษที่จะทำและจะไม่ปรับปรุงสิ่งต่าง ๆ (จริง ๆ )

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

โซลูชันแบบคลาสสิกมีลักษณะดังนี้:

[user] [front-end] [machine1] [common resources]
                   [machine2]
                   [machine3]

ระหว่างเครื่อง front-end และเครื่องคำนวณคุณอาจมีสิ่งพิเศษเช่น load balancer และการตรวจสอบประสิทธิภาพและการประมวลผลแบบพิเศษบนเครื่องจักรเฉพาะนั้นดีสำหรับการแคชและการเพิ่มประสิทธิภาพของปริมาณงาน

สิ่งนี้ไม่ได้บอกเป็นนัยถึงการโหลด / ขนถ่าย DLLs พิเศษหรืออะไรที่เกี่ยวข้องกับ STL

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

สิ่งนี้กล่าวว่าด้วยข้อมูลที่ จำกัด ที่คุณให้มานี่ดูเหมือนปัญหา xy แบบคลาสสิก (ตามที่ @Graham พูด)