ECS? ฉันจะแนะนำว่ามันอาจจะไม่เกิดขึ้นก่อนกำหนดหากคิดอย่างมากในด้านการออกแบบข้อมูลและตัวแทนมาตรฐานที่แตกต่างกันเพราะมันอาจส่งผลกระทบต่อการออกแบบส่วนต่อประสานของคุณและอันหลังนั้นมีค่าใช้จ่ายสูงมาก เกม. นอกจากนี้ ECS ยังต้องการงานจำนวนมากและคิดล่วงหน้าและฉันคิดว่ามันคุ้มค่าที่จะใช้เวลาในการทำให้แน่ใจว่ามันจะไม่ทำให้คุณมีความเศร้าโศกในระดับประสิทธิภาพการออกแบบต่อไปตามแนวทางที่เป็นหัวใจของคุณ เครื่องยนต์ที่ซบเซา ส่วนนี้จ้องมองมาที่ฉัน:
unordered_map<string,[yada]>
แม้ว่าจะมีการเพิ่มประสิทธิภาพสตริงขนาดเล็กคุณยังมีคอนเทนเนอร์ขนาดตัวแปร (สตริง) ภายในคอนเทนเนอร์ขนาดตัวแปรอื่น (unordered_maps) ในความเป็นจริงการเพิ่มประสิทธิภาพสตริงขนาดเล็กจริงอาจจะเป็นอันตรายเป็นประโยชน์ในกรณีนี้ถ้าตารางของคุณเป็นอย่างมากที่เบาบางเนื่องจากการเพิ่มประสิทธิภาพสตริงขนาดเล็กจะบ่งบอกว่าแต่ละดัชนีไม่ได้ใช้ของตารางแฮชจะยังคงใช้หน่วยความจำมากขึ้นสำหรับการเพิ่มประสิทธิภาพของเอสเอส ( sizeof(string)จะ ใหญ่กว่า) จนถึงจุดที่ค่าใช้จ่ายหน่วยความจำรวมของตารางแฮชของคุณอาจมีราคาสูงกว่าสิ่งที่คุณเก็บไว้โดยเฉพาะอย่างยิ่งถ้ามันเป็นองค์ประกอบที่เรียบง่ายเช่นองค์ประกอบตำแหน่งนอกจากจะทำให้แคชหายไปมากกว่าเดิมแล้ว เพื่อรับจากหนึ่งรายการในตารางแฮชไปยังถัดไป
ฉันสมมติว่าสตริงเป็นคีย์บางชนิดเช่น ID ส่วนประกอบ ถ้าเป็นเช่นนั้นสิ่งนี้ทำให้ราคาถูกลงอย่างมากแล้ว:
unordered_map<int,[yada]>
... หากคุณต้องการได้รับประโยชน์จากความสามารถในการมีชื่อที่ใช้งานง่ายที่สแครปเตอร์สามารถใช้งานได้เช่นจากนั้นสตริงการฝึกงานสามารถมอบสิ่งที่ดีที่สุดให้กับทั้งสองโลกได้
ที่กล่าวว่าหากคุณสามารถจับคู่สตริงกับดัชนีที่มีการใช้หนาแน่นในระดับที่สมเหตุสมผลคุณอาจทำได้ดังนี้:
vector<[yada]> // the index and key become one and the same
เหตุผลที่ฉันไม่พิจารณาก่อนวัยอันควรนี้ก็เพราะว่ามันอาจส่งผลกระทบต่อการออกแบบอินเตอร์เฟสของคุณอีกครั้ง ประเด็นของ DOD ไม่ควรพยายามที่จะนำเสนอข้อมูลที่มีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้ใน IMO เพียงครั้งเดียว (ซึ่งโดยทั่วไปควรจะทำได้ตามที่จำเป็น) แต่ให้คิดถึงการออกแบบอินเทอร์เฟซที่ใช้งานได้ ข้อมูลที่ทำให้คุณมีห้องหายใจเพียงพอที่จะสร้างโปรไฟล์และปรับให้เหมาะสมโดยไม่ต้องเปลี่ยนการออกแบบที่เรียงซ้อน
เป็นตัวอย่างที่ไร้เดียงสาซอฟต์แวร์ประมวลผลวิดีโอที่จับคู่โค้ดทั้งหมดกับสิ่งนี้:
// Abstract pixel that could be concretely represented by
// RGB, BGR, RGBA, BGRA, 1-bit channels, 8-bit channels,
// 16-bit channels, 32-bit channels, grayscale, monochrome,
// etc. pixels.
class IPixel
{
public:
virtual ~IPixel() {}
...
};
จะไม่ไปไกลโดยไม่ต้องเขียนมหากาพย์ที่อาจเกิดขึ้นเนื่องจากความคิดของการนามธรรมที่ระดับพิกเซลเดียวนั้นไม่มีประสิทธิภาพมาก ( vptrตัวเองมักจะมีค่าใช้จ่ายหน่วยความจำมากกว่าพิกเซลทั้งหมด) เมื่อเทียบกับนามธรรมที่ระดับภาพ (ซึ่งจะ มักแสดงถึงล้านพิกเซล) ดังนั้นคิดให้มากพอที่จะนำเสนอข้อมูลของคุณล่วงหน้าเพื่อที่คุณจะได้ไม่ต้องเผชิญกับสถานการณ์ฝันร้ายและไม่ต้องนึกถึงอีกต่อไป แต่ที่นี่ฉันคิดว่ามันคุ้มค่าที่จะคิดถึงสิ่งนี้ตั้งแต่ที่คุณไม่ต้องการสร้าง เอนจิ้นที่ซับซ้อนรอบ ๆ ECS ของคุณและพบว่า ECS นั้นเป็นคอขวดด้วยวิธีที่ทำให้คุณต้องเปลี่ยนแปลงสิ่งต่าง ๆ ในระดับการออกแบบ
สำหรับการที่แคชของ ECS ขาดหายไปในความคิดเห็นของฉันนักพัฒนามักจะพยายามอย่างหนักที่จะทำให้แคชของ ECS เป็นมิตร มันเริ่มให้ผลน้อยเกินไปสำหรับเจ้าชู้ที่จะพยายามเข้าถึงส่วนประกอบทั้งหมดของคุณในแบบที่ต่อเนื่องกันอย่างสมบูรณ์และมักจะบ่งบอกถึงการคัดลอกและสับข้อมูลทั่วสถานที่ ปกติแล้วมันจะดีพอที่จะพูดเพียงแค่ดัชนีเรดเด็นซ์องค์ประกอบก่อนที่จะเข้าถึงพวกมันเพื่อที่คุณจะเข้าถึงพวกมันในแบบที่คุณอย่างน้อยก็ไม่ได้โหลดส่วนหน่วยความจำลงในแคชแถวเพื่อขับไล่เท่านั้น มันซ้ำแล้วซ้ำอีกในลูปเดียวกันเพื่อเข้าถึงส่วนต่าง ๆ ของบรรทัดแคชเดียวกัน และ ECS ไม่จำเป็นต้องให้ประสิทธิภาพที่น่าทึ่งทั่วทั้งกระดาน มันไม่เหมือนกับระบบอินพุตที่ได้ประโยชน์จากระบบฟิสิกส์หรือระบบเรนเดอร์ดังนั้นฉันจึงแนะนำให้ตั้งเป้าหมายว่า "ดี" ประสิทธิภาพทั่วกระดานและ "ยอดเยี่ยม" เพียงในสถานที่ที่คุณต้องการจริงๆ ที่กล่าวว่าการใช้unordered_mapและstringที่นี่ง่ายพอที่จะหลีกเลี่ยง