. NET มีค่าใช้จ่ายเท่าใด

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

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

มันคือ. แต่นั่นก็ขึ้นอยู่กับสิ่งที่คุณพยายามจะทำ

ฉันใช้การไตร่ตรองเพื่อโหลดแอสเซมบลี (ปลั๊กอิน) แบบไดนามิกและประสิทธิภาพ "การลงโทษ" ไม่ใช่ปัญหาเนื่องจากการดำเนินการเป็นสิ่งที่ฉันทำในระหว่างการเริ่มต้นแอปพลิเคชัน

อย่างไรก็ตามหากคุณสะท้อนอยู่ในชุดของลูปซ้อนกันที่มีการสะท้อนการโทรในแต่ละครั้งฉันจะบอกว่าคุณควรกลับมาใช้รหัสของคุณอีกครั้ง :)

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

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

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

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

ฉันคิดการทดสอบที่ฉันคิดว่ามีความยุติธรรมเพราะมันเก็บสายที่เกิดขึ้นซ้ำทั้งหมดและเฉพาะเวลาที่โทร SetValue หรือ GetValue จริง ซอร์สโค้ดทั้งหมดสำหรับการทดสอบประสิทธิภาพอยู่ใน bitbucket ที่: https://bitbucket.org/grenade/accessortest https://bitbucket.org/grenade/accessortestการตรวจสอบข้อเท็จจริงยินดีต้อนรับและสนับสนุน

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

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

หากคุณไม่ได้อยู่ในวงไม่ต้องกังวลกับมัน

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

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

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

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

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

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

ตัวอย่างต่อไปนี้ล้าสมัย - จริงในเวลา (2008) แต่ได้รับการแก้ไขนานมาแล้วในเวอร์ชัน CLR ล่าสุด การสะท้อนโดยทั่วไปยังคงเป็นสิ่งที่ค่อนข้างแพง!

กรณีตรงประเด็น: คุณไม่ควรใช้สมาชิกที่ประกาศว่า "Object" ในคำสั่ง lock (C #) / SyncLock (VB.NET) ในรหัสประสิทธิภาพสูง ทำไม? เนื่องจาก CLR ไม่สามารถล็อคกับประเภทค่าได้ซึ่งหมายความว่าจะต้องทำการตรวจสอบชนิดการสะท้อนเวลาทำงานเพื่อดูว่าวัตถุของคุณเป็นประเภทค่าจริงหรือไม่แทนประเภทการอ้างอิง

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

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

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

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

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

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

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

แหย่รอบแหล่งที่มาและดูว่ากำลังทำอะไรอยู่

ทุกอย่างเกี่ยวกับการประเมินสถานการณ์ ในDotNetNukeมีองค์ประกอบหลักที่เป็นธรรมที่เรียกFillObjectว่าการสะท้อนเพื่อเติมวัตถุจาก datarows

นี่เป็นสถานการณ์ทั่วไปที่พบได้ทั่วไปและมีบทความเกี่ยวกับ MSDN โดยใช้ Reflection to Bind Business Objects ไปยังการควบคุมฟอร์ม ASP.NETที่ครอบคลุมปัญหาด้านประสิทธิภาพ

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

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

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