ບົດຄວາມທີ່ບໍ່ປະສົບຜົນສໍາເລັດກ່ຽວກັບການເລັ່ງການສະທ້ອນ

ຂ້ອຍຈະອະທິບາຍຫົວຂໍ້ຂອງບົດຄວາມທັນທີ. ແຜນການຕົ້ນສະບັບແມ່ນໃຫ້ຄໍາແນະນໍາທີ່ດີແລະເຊື່ອຖືໄດ້ກ່ຽວກັບວິທີການເລັ່ງການໃຊ້ການສະທ້ອນໂດຍໃຊ້ຕົວຢ່າງທີ່ງ່າຍດາຍແຕ່ເປັນຈິງ, ແຕ່ໃນລະຫວ່າງການ benchmarking ມັນໄດ້ສະແດງໃຫ້ເຫັນວ່າການສະທ້ອນບໍ່ຊ້າຄືທີ່ຂ້ອຍຄິດ, LINQ ແມ່ນຊ້າກວ່າໃນຝັນຮ້າຍຂອງຂ້ອຍ. ແຕ່ໃນທີ່ສຸດມັນໄດ້ຫັນອອກວ່າຂ້ອຍຍັງເຮັດຜິດພາດໃນການວັດແທກ ... ລາຍລະອຽດຂອງເລື່ອງຊີວິດນີ້ແມ່ນຢູ່ພາຍໃຕ້ການຕັດແລະໃນຄໍາເຫັນ. ນັບຕັ້ງແຕ່ຕົວຢ່າງແມ່ນຂ້ອນຂ້າງທົ່ວໄປແລະຖືກປະຕິບັດໃນຫຼັກການຕາມປົກກະຕິໃນວິສາຫະກິດ, ມັນໄດ້ກາຍເປັນທີ່ຫນ້າສົນໃຈຫຼາຍ, ຍ້ອນວ່າມັນເບິ່ງຄືວ່າຂ້ອຍ, ການສາທິດຊີວິດ: ຜົນກະທົບຕໍ່ຄວາມໄວຂອງຫົວຂໍ້ຕົ້ນຕໍຂອງບົດຄວາມແມ່ນ. ບໍ່ສັງເກດເຫັນຍ້ອນເຫດຜົນພາຍນອກ: Moq, Autofac, EF Core ແລະອື່ນໆ "bandings".

ຂ້ອຍເລີ່ມເຮັດວຽກພາຍໃຕ້ຄວາມປະທັບໃຈຂອງບົດຄວາມນີ້: ເປັນຫຍັງການສະທ້ອນຊ້າ

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ຜູ້ຂຽນແນະນໍາໃຫ້ໃຊ້ຜູ້ແທນທີ່ລວບລວມແທນທີ່ຈະໂທຫາວິທີການປະເພດການສະທ້ອນໂດຍກົງເປັນວິທີທີ່ດີທີ່ຈະເພີ່ມຄວາມໄວຂອງແອັບພລິເຄຊັນ. ແນ່ນອນ, ມີການປ່ອຍອາຍພິດ IL, ແຕ່ຂ້ອຍຢາກຫຼີກລ້ຽງມັນ, ເພາະວ່ານີ້ແມ່ນວິທີການທີ່ໃຊ້ແຮງງານຫຼາຍທີ່ສຸດໃນການປະຕິບັດວຽກງານ, ເຊິ່ງມີຄວາມຜິດພາດຫຼາຍ.

ພິຈາລະນາວ່າຂ້ອຍມີຄວາມຄິດເຫັນທີ່ຄ້າຍຄືກັນສະເຫມີກ່ຽວກັບຄວາມໄວຂອງການສະທ້ອນ, ຂ້ອຍບໍ່ຕັ້ງໃຈໂດຍສະເພາະຄໍາຖາມບົດສະຫຼຸບຂອງຜູ້ຂຽນ.

ຂ້າພະເຈົ້າມັກຈະພົບກັບການນໍາໃຊ້ naive ຂອງສະທ້ອນໃຫ້ເຫັນໃນວິສາຫະກິດ. ປະເພດແມ່ນປະຕິບັດ. ຂໍ້ມູນກ່ຽວກັບຊັບສິນໄດ້ຖືກປະຕິບັດ. ວິທີການ SetValue ຖືກເອີ້ນວ່າແລະທຸກຄົນປິຕິຍິນດີ. ມູນຄ່າໄດ້ມາຮອດພາກສະຫນາມເປົ້າຫມາຍ, ທຸກຄົນມີຄວາມສຸກ. ຄົນສະຫຼາດຫຼາຍ - ຜູ້ອາວຸໂສແລະທີມງານນໍາພາ - ຂຽນສ່ວນຂະຫຍາຍຂອງພວກເຂົາເພື່ອຄັດຄ້ານ, ໂດຍອີງໃສ່ການປະຕິບັດແບບໂງ່ໆ "ທົ່ວໄປ" ແຜນທີ່ຂອງປະເພດຫນຶ່ງໄປຫາຄົນອື່ນ. ໂດຍເນື້ອແທ້ແລ້ວແມ່ນນີ້: ພວກເຮົາເອົາພາກສະຫນາມທັງຫມົດ, ເອົາຄຸນສົມບັດທັງຫມົດ, ຊ້ໍາມັນ: ຖ້າຊື່ຂອງສະມາຊິກປະເພດກົງກັນ, ພວກເຮົາປະຕິບັດ SetValue. ບາງຄັ້ງພວກເຮົາຈັບຂໍ້ຍົກເວັ້ນຍ້ອນຄວາມຜິດພາດທີ່ພວກເຮົາບໍ່ໄດ້ຊອກຫາຊັບສິນບາງຢ່າງໃນປະເພດຫນຶ່ງ, ແຕ່ເຖິງແມ່ນວ່າໃນທີ່ນີ້ມີທາງອອກທີ່ປັບປຸງການປະຕິບັດ. ພະຍາຍາມ / ຈັບ.

ຂ້ອຍໄດ້ເຫັນຄົນປະດິດຕົວວິເຄາະ ແລະ ແຜນທີ່ຄືນໃໝ່ ໂດຍບໍ່ໄດ້ປະກອບອາວຸດເຕັມທີ່ດ້ວຍຂໍ້ມູນກ່ຽວກັບເຄື່ອງຈັກທີ່ເຂົ້າມາກ່ອນພວກມັນເຮັດວຽກແນວໃດ. ຂ້າພະເຈົ້າໄດ້ເຫັນປະຊາຊົນຊ່ອນການປະຕິບັດທີ່ໄຮ້ດຽງສາຂອງເຂົາເຈົ້າຢູ່ເບື້ອງຫຼັງຍຸດທະສາດ, ຫລັງການໂຕ້ຕອບ, ຫລັງການສັກຢາ, ຄືກັບວ່ານີ້ຈະແກ້ຕົວຕໍ່ bacchanalia ຕໍ່ມາ. ຂ້າພະເຈົ້າໄດ້ຫັນດັງຂອງຂ້າພະເຈົ້າຂຶ້ນຢູ່ໃນຄວາມເປັນຈິງດັ່ງກ່າວ. ໃນຄວາມເປັນຈິງ, ຂ້າພະເຈົ້າບໍ່ໄດ້ວັດແທກການຮົ່ວໄຫລຂອງການປະຕິບັດຕົວຈິງ, ແລະ, ຖ້າເປັນໄປໄດ້, ຂ້າພະເຈົ້າພຽງແຕ່ປ່ຽນການປະຕິບັດເປັນ "ທີ່ດີທີ່ສຸດ" ຖ້າຂ້ອຍສາມາດເອົາມືຂອງຂ້ອຍໄປ. ດັ່ງນັ້ນ, ການວັດແທກທໍາອິດທີ່ໄດ້ປຶກສາຫາລືຂ້າງລຸ່ມນີ້ເຮັດໃຫ້ຂ້ອຍສັບສົນຢ່າງຈິງຈັງ.

ຂ້າພະເຈົ້າຄິດວ່າຫຼາຍໆທ່ານ, ອ່ານ Richter ຫຼືນັກອຸດົມການອື່ນໆ, ໄດ້ພົບກັບຄໍາຖະແຫຼງທີ່ຍຸຕິທໍາຢ່າງສົມບູນວ່າການສະທ້ອນໃນລະຫັດແມ່ນປະກົດການທີ່ມີຜົນກະທົບທາງລົບທີ່ສຸດຕໍ່ການປະຕິບັດຂອງຄໍາຮ້ອງສະຫມັກ.

ການສະທ້ອນການໂທບັງຄັບໃຫ້ CLR ໄປຜ່ານສະພາແຫ່ງເພື່ອຊອກຫາສິ່ງທີ່ເຂົາເຈົ້າຕ້ອງການ, ດຶງຂໍ້ມູນ metadata ຂອງເຂົາເຈົ້າ, parse, ແລະອື່ນໆ. ນອກຈາກນັ້ນ, ການສະທ້ອນໃນຂະນະທີ່ traversing ລໍາດັບນໍາໄປສູ່ການຈັດສັນຈໍານວນຂະຫນາດໃຫຍ່ຂອງຫນ່ວຍຄວາມຈໍາ. ພວກເຮົາກໍາລັງໃຊ້ຫນ່ວຍຄວາມຈໍາ, CLR ເປີດເຜີຍ GC ແລະ friezes ເລີ່ມຕົ້ນ. ມັນຄວນຈະຊ້າຢ່າງຈະແຈ້ງ, ເຊື່ອຂ້ອຍ. ຈໍານວນຫນ່ວຍຄວາມຈໍາຈໍານວນຫຼວງຫຼາຍໃນເຄື່ອງແມ່ຂ່າຍການຜະລິດທີ່ທັນສະໄຫມຫຼືເຄື່ອງຈັກຟັງບໍ່ໄດ້ປ້ອງກັນຄວາມລ່າຊ້າໃນການປຸງແຕ່ງສູງ. ໃນຄວາມເປັນຈິງ, ຄວາມຊົງຈໍາຫຼາຍ, ທ່ານມັກຈະສັງເກດເຫັນວິທີການເຮັດວຽກຂອງ GC. ການສະທ້ອນແມ່ນ, ໃນທາງທິດສະດີ, ເປັນຜ້າສີແດງພິເສດສໍາລັບລາວ.

ເຖິງຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາທຸກຄົນໃຊ້ IoC containers ແລະ date mappers, ຫຼັກການປະຕິບັດງານຍັງອີງໃສ່ການສະທ້ອນ, ແຕ່ປົກກະຕິແລ້ວບໍ່ມີຄໍາຖາມກ່ຽວກັບການປະຕິບັດຂອງມັນ. ບໍ່, ບໍ່ແມ່ນຍ້ອນວ່າການແນະນໍາການເພິ່ງພາອາໄສແລະການບໍ່ມີຕົວຕົນຈາກຕົວແບບສະພາບການທີ່ຈໍາກັດພາຍນອກແມ່ນມີຄວາມຈໍາເປັນຫຼາຍທີ່ພວກເຮົາຕ້ອງເສຍສະລະການປະຕິບັດໃນກໍລະນີໃດກໍ່ຕາມ. ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ - ມັນກໍ່ບໍ່ມີຜົນຕໍ່ການປະຕິບັດຫຼາຍ.

ຄວາມຈິງແລ້ວແມ່ນວ່າໂຄງຮ່າງການທົ່ວໄປທີ່ສຸດທີ່ອີງໃສ່ເຕັກໂນໂລຢີການສະທ້ອນນໍາໃຊ້ທຸກປະເພດຂອງ tricks ເພື່ອເຮັດວຽກກັບມັນທີ່ດີທີ່ສຸດ. ປົກກະຕິແລ້ວນີ້ແມ່ນ cache. ໂດຍປົກກະຕິເຫຼົ່ານີ້ແມ່ນການສະແດງອອກແລະຜູ້ແທນທີ່ລວບລວມຈາກຕົ້ນໄມ້ສະແດງອອກ. automapper ດຽວກັນຮັກສາວັດຈະນານຸກົມທີ່ມີການແຂ່ງຂັນທີ່ກົງກັບປະເພດຕ່າງໆທີ່ມີຫນ້າທີ່ທີ່ສາມາດປ່ຽນເປັນອັນອື່ນໂດຍບໍ່ຕ້ອງໂທຫາການສະທ້ອນ.

ນີ້ບັນລຸໄດ້ແນວໃດ? ໂດຍພື້ນຖານແລ້ວ, ນີ້ບໍ່ແມ່ນສິ່ງທີ່ແຕກຕ່າງຈາກເຫດຜົນທີ່ເວທີຕົວມັນເອງໃຊ້ເພື່ອສ້າງລະຫັດ JIT. ເມື່ອວິທີການຖືກເອີ້ນເປັນຄັ້ງທໍາອິດ, ມັນຖືກລວບລວມ (ແລະ, ແມ່ນແລ້ວ, ຂະບວນການນີ້ແມ່ນບໍ່ໄວ); ໃນການໂທຕໍ່ມາ, ການຄວບຄຸມຈະຖືກໂອນໄປຫາວິທີການລວບລວມແລ້ວ, ແລະຈະບໍ່ມີການດຶງການປະຕິບັດທີ່ສໍາຄັນ.

ໃນກໍລະນີຂອງພວກເຮົາ, ທ່ານຍັງສາມາດນໍາໃຊ້ການລວບລວມ JIT ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ພຶດຕິກໍາການລວບລວມດ້ວຍການປະຕິບັດດຽວກັນກັບຄູ່ຮ່ວມງານຂອງ AOT. ການສະແດງອອກຈະມາຊ່ວຍເຫຼືອຂອງພວກເຮົາໃນກໍລະນີນີ້.

ຫຼັກ​ການ​ໃນ​ຄໍາ​ຖາມ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ສ້າງ​ຕັ້ງ​ໂດຍ​ຫຍໍ້​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:
ທ່ານຄວນເກັບຂໍ້ມູນສຸດທ້າຍຂອງການສະທ້ອນເປັນຕົວແທນທີ່ມີຫນ້າທີ່ລວບລວມ. ມັນຍັງເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະ cache ວັດຖຸທີ່ຈໍາເປັນທັງຫມົດທີ່ມີຂໍ້ມູນປະເພດໃນຂົງເຂດຂອງປະເພດຂອງທ່ານ, ພະນັກງານ, ທີ່ຖືກເກັບໄວ້ນອກວັດຖຸ.

ມີເຫດຜົນໃນເລື່ອງນີ້. ຄວາມຮູ້ສຶກທົ່ວໄປບອກພວກເຮົາວ່າຖ້າບາງສິ່ງບາງຢ່າງສາມາດລວບລວມແລະເກັບໄວ້ໃນຖານຄວາມຈໍາ, ມັນຄວນຈະເຮັດ.

ເບິ່ງໄປຂ້າງຫນ້າ, ມັນຄວນຈະເວົ້າວ່າ cache ໃນການເຮັດວຽກກັບການສະທ້ອນມີຂໍ້ດີຂອງມັນ, ເຖິງແມ່ນວ່າທ່ານບໍ່ໄດ້ໃຊ້ວິທີການທີ່ສະເຫນີຂອງການລວບລວມການສະແດງອອກ. ແທ້ຈິງແລ້ວ, ໃນທີ່ນີ້ຂ້າພະເຈົ້າພຽງແຕ່ເຮັດຊ້ໍາສິ່ງເຫຼົ່ານີ້ຂອງຜູ້ຂຽນຂອງບົດຄວາມທີ່ຂ້າພະເຈົ້າອ້າງເຖິງຂ້າງເທິງ.

ໃນປັດຈຸບັນກ່ຽວກັບລະຫັດ. ໃຫ້ເບິ່ງຕົວຢ່າງທີ່ອີງໃສ່ຄວາມເຈັບປວດທີ່ຜ່ານມາຂອງຂ້ອຍທີ່ຂ້ອຍຕ້ອງປະເຊີນກັບການຜະລິດຂອງສະຖາບັນສິນເຊື່ອທີ່ຮ້າຍແຮງ. ຫນ່ວຍງານທັງຫມົດແມ່ນສົມມຸດຕິຖານເພື່ອບໍ່ມີໃຜຄາດເດົາ.

ມີບາງເນື້ອແທ້ແລ້ວ. ໃຫ້​ມີ​ການ​ຕິດ​ຕໍ່​. ມີຕົວອັກສອນທີ່ມີຮ່າງກາຍມາດຕະຖານ, ຈາກທີ່ parser ແລະ hydrator ສ້າງການຕິດຕໍ່ດຽວກັນເຫຼົ່ານີ້. ຈົດໝາຍມາຮອດ, ພວກເຮົາອ່ານມັນ, ແຍກມັນອອກເປັນຄູ່ຄີ-ມູນຄ່າ, ສ້າງການຕິດຕໍ່, ແລະບັນທຶກມັນໄວ້ໃນຖານຂໍ້ມູນ.

ມັນເປັນປະຖົມ. ໃຫ້ເວົ້າວ່າຜູ້ຕິດຕໍ່ມີຄຸນສົມບັດຊື່ເຕັມ, ອາຍຸແລະໂທລະສັບຕິດຕໍ່. ຂໍ້ມູນນີ້ຖືກສົ່ງໃນຈົດຫມາຍ. ທຸລະກິດຍັງຕ້ອງການການສະຫນັບສະຫນູນເພື່ອໃຫ້ສາມາດເພີ່ມກະແຈໃຫມ່ຢ່າງໄວວາສໍາລັບການສ້າງແຜນທີ່ຄຸນສົມບັດຂອງຫນ່ວຍງານເຂົ້າໄປໃນຄູ່ຢູ່ໃນຕົວຫນັງສື. ໃນກໍລະນີທີ່ຜູ້ໃດຜູ້ ໜຶ່ງ ພິມຜິດໃນແມ່ແບບຫຼືຖ້າກ່ອນທີ່ຈະປ່ອຍມັນ ຈຳ ເປັນຕ້ອງເປີດແຜນທີ່ຈາກຄູ່ຮ່ວມງານ ໃໝ່, ປັບຕົວເຂົ້າກັບຮູບແບບ ໃໝ່. ຫຼັງຈາກນັ້ນ, ພວກເຮົາສາມາດເພີ່ມການເຊື່ອມໂຍງແຜນທີ່ໃຫມ່ເປັນ datafix ລາຄາຖືກ. ນັ້ນແມ່ນ, ຕົວຢ່າງຊີວິດ.

ພວກເຮົາປະຕິບັດ, ສ້າງການທົດສອບ. ເຮັດວຽກ.

ຂ້ອຍຈະບໍ່ໃຫ້ລະຫັດ: ມີຫຼາຍແຫຼ່ງ, ແລະພວກມັນມີຢູ່ໃນ GitHub ຜ່ານການເຊື່ອມຕໍ່ໃນຕອນທ້າຍຂອງບົດຄວາມ. ທ່ານສາມາດໂຫຼດພວກມັນ, ທໍລະມານພວກເຂົາເກີນກວ່າການຮັບຮູ້ແລະວັດແທກພວກມັນ, ເພາະວ່າມັນຈະສົ່ງຜົນກະທົບຕໍ່ໃນກໍລະນີຂອງທ່ານ. ຂ້າພະເຈົ້າຈະໃຫ້ລະຫັດຂອງສອງວິທີແມ່ແບບທີ່ແຍກແຍະ hydrator, ເຊິ່ງຄາດວ່າຈະໄວ, ຈາກ hydrator, ເຊິ່ງຄາດວ່າຈະຊ້າ.

ເຫດຜົນມີດັ່ງນີ້: ວິທີການແມ່ແບບໄດ້ຮັບຄູ່ທີ່ສ້າງຂຶ້ນໂດຍເຫດຜົນ parser ພື້ນຖານ. ຊັ້ນ LINQ ແມ່ນ parser ແລະເຫດຜົນພື້ນຖານຂອງ hydrator, ເຊິ່ງເຮັດໃຫ້ການຮ້ອງຂໍກັບສະພາບການຖານຂໍ້ມູນແລະປຽບທຽບຄີກັບຄູ່ຈາກ parser (ສໍາລັບຫນ້າທີ່ເຫຼົ່ານີ້ມີລະຫັດທີ່ບໍ່ມີ LINQ ສໍາລັບການປຽບທຽບ). ຕໍ່ໄປ, ຄູ່ຖືກສົ່ງກັບວິທີການ hydration ຕົ້ນຕໍແລະຄ່າຂອງຄູ່ແມ່ນຖືກກໍານົດໃຫ້ກັບຄຸນສົມບັດທີ່ສອດຄ້ອງກັນຂອງຫນ່ວຍງານ.

“ໄວ” (Prefix Fast in benchmarks):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

ດັ່ງທີ່ພວກເຮົາສາມາດເຫັນໄດ້, ການເກັບກໍາແບບຄົງທີ່ທີ່ມີຄຸນສົມບັດຂອງ setter ແມ່ນຖືກນໍາໃຊ້ - lambdas ລວບລວມທີ່ໂທຫາຫນ່ວຍງານ setter . ສ້າງໂດຍລະຫັດຕໍ່ໄປນີ້:

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

ໂດຍທົ່ວໄປມັນຈະແຈ້ງ. ພວກເຮົາຂ້າມຄຸນສົມບັດ, ສ້າງຕົວແທນສໍາລັບພວກເຂົາທີ່ໂທຫາຜູ້ຕັ້ງ, ແລະປະຫຍັດພວກມັນ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາໂທຫາໃນເວລາທີ່ມີຄວາມຈໍາເປັນ.

"ຊ້າ" (ຄໍານໍາຫນ້າຊ້າໃນມາດຕະຖານ):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

ໃນທີ່ນີ້ພວກເຮົາທັນທີຂ້າມຄຸນສົມບັດແລະໂທຫາ SetValue ໂດຍກົງ.

ເພື່ອຄວາມຊັດເຈນແລະເປັນການອ້າງອິງ, ຂ້າພະເຈົ້າໄດ້ປະຕິບັດວິທີການ naive ທີ່ຂຽນຄ່າຂອງຄູ່ຄວາມສໍາພັນຂອງເຂົາເຈົ້າໂດຍກົງເຂົ້າໄປໃນຊ່ອງຂໍ້ມູນຫນ່ວຍງານ. ຄໍານໍາຫນ້າ - ຄູ່ມື.

ຕອນນີ້ໃຫ້ເອົາ BenchmarkDotNet ແລະກວດເບິ່ງການປະຕິບັດ. ແລະທັນທີທັນໃດ ... (spoiler - ນີ້ບໍ່ແມ່ນຜົນໄດ້ຮັບທີ່ຖືກຕ້ອງ, ລາຍລະອຽດແມ່ນຂ້າງລຸ່ມນີ້)

ພວກເຮົາເຫັນຫຍັງຢູ່ນີ້? ວິທີການທີ່ຊະນະຄຳນຳໜ້າ Fast ປະກົດວ່າຊ້າກວ່າໃນເກືອບທຸກຂັ້ນຕອນກວ່າວິທີການທີ່ມີຄຳນຳໜ້າຊ້າ. ນີ້ແມ່ນຄວາມຈິງສໍາລັບທັງການຈັດສັນແລະຄວາມໄວຂອງການເຮັດວຽກ. ໃນທາງກົງກັນຂ້າມ, ການປະຕິບັດແຜນທີ່ທີ່ສວຍງາມແລະສະຫງ່າງາມໂດຍນໍາໃຊ້ວິທີການ LINQ ທີ່ມີຈຸດປະສົງສໍາລັບການນີ້ບ່ອນໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້, ໃນທາງກົງກັນຂ້າມ, ຫຼຸດລົງຜົນຜະລິດຢ່າງຫຼວງຫຼາຍ. ຄວາມແຕກຕ່າງແມ່ນຄໍາສັ່ງ. ທ່າອ່ຽງບໍ່ປ່ຽນແປງດ້ວຍຕົວເລກທີ່ແຕກຕ່າງກັນຂອງການຜ່ານ. ຄວາມແຕກຕ່າງພຽງແຕ່ຢູ່ໃນຂະຫນາດ. ດ້ວຍ LINQ ມັນຊ້າກວ່າ 4 - 200 ເທົ່າ, ມີຂີ້ເຫຍື້ອຫຼາຍກວ່າໃນຂະຫນາດດຽວກັນ.

ປັບປຸງ

ຂ້ອຍບໍ່ເຊື່ອຕາຂອງຂ້ອຍ, ແຕ່ສໍາຄັນກວ່ານັ້ນ, ເພື່ອນຮ່ວມງານຂອງພວກເຮົາບໍ່ເຊື່ອຕາຂອງຂ້ອຍຫຼືລະຫັດຂອງຂ້ອຍ - Dmitry Tikhonov 0x1000000. ມີການກວດສອບການແກ້ໄຂຂອງຂ້ອຍສອງຄັ້ງ, ລາວໄດ້ຄົ້ນພົບຢ່າງສະຫຼາດແລະຊີ້ໃຫ້ເຫັນຄວາມຜິດພາດທີ່ຂ້ອຍພາດເນື່ອງຈາກການປ່ຽນແປງຈໍານວນຫນຶ່ງໃນການປະຕິບັດ, ເບື້ອງຕົ້ນເຖິງຂັ້ນສຸດທ້າຍ. ຫຼັງ​ຈາກ​ການ​ແກ້​ໄຂ bug ທີ່​ພົບ​ເຫັນ​ໃນ​ການ​ຕິດ​ຕັ້ງ Moq​, ຜົນ​ໄດ້​ຮັບ​ທັງ​ຫມົດ​ໄດ້​ຕົກ​ເຂົ້າ​ໄປ​ໃນ​ສະ​ຖານ​ທີ່​. ອີງຕາມຜົນໄດ້ຮັບຂອງການທົດສອບຄືນໃຫມ່, ແນວໂນ້ມຕົ້ນຕໍບໍ່ປ່ຽນແປງ - LINQ ຍັງມີຜົນກະທົບຕໍ່ການປະຕິບັດຫຼາຍກ່ວາການສະທ້ອນ. ຢ່າງໃດກໍຕາມ, ມັນເປັນການດີທີ່ການເຮັດວຽກກັບການລວບລວມການສະແດງອອກບໍ່ໄດ້ເຮັດໃນໄຮ້ປະໂຍດ, ແລະຜົນໄດ້ຮັບແມ່ນເຫັນໄດ້ຊັດເຈນທັງໃນການຈັດສັນແລະເວລາປະຕິບັດ. ການເປີດຕົວຄັ້ງທໍາອິດ, ໃນເວລາທີ່ພາກສະຫນາມ static ແມ່ນເບື້ອງຕົ້ນ, ແມ່ນຊ້າກວ່າທໍາມະຊາດສໍາລັບວິທີການ "ໄວ", ແຕ່ຫຼັງຈາກນັ້ນສະຖານະການມີການປ່ຽນແປງ.

ນີ້ແມ່ນຜົນຂອງການທົດສອບຄືນ:

ສະຫຼຸບ: ເມື່ອນໍາໃຊ້ການສະທ້ອນໃນວິສາຫະກິດ, ບໍ່ຈໍາເປັນຕ້ອງໃຊ້ການຫລອກລວງໂດຍສະເພາະ - LINQ ຈະກິນຜົນຜະລິດຫຼາຍ. ຢ່າງໃດກໍຕາມ, ໃນວິທີການໂຫຼດສູງທີ່ຕ້ອງການການເພີ່ມປະສິດທິພາບ, ທ່ານສາມາດປະຫຍັດການສະທ້ອນໃນຮູບແບບຂອງຕົວກໍານົດເບື້ອງຕົ້ນແລະຜູ້ລວບລວມຂໍ້ມູນ, ເຊິ່ງຫຼັງຈາກນັ້ນຈະໃຫ້ເຫດຜົນ "ໄວ". ວິທີນີ້ທ່ານສາມາດຮັກສາທັງຄວາມຍືດຫຍຸ່ນຂອງການສະທ້ອນແລະຄວາມໄວຂອງຄໍາຮ້ອງສະຫມັກ.

ລະຫັດມາດຕະຖານແມ່ນມີຢູ່ບ່ອນນີ້. ທຸກຄົນສາມາດກວດຄືນຄຳສັບຂອງຂ້ອຍໄດ້:
HabraReflectionTests

PS: ລະຫັດໃນການທົດສອບໃຊ້ IoC, ແລະໃນ benchmarks ມັນໃຊ້ໂຄງສ້າງທີ່ຊັດເຈນ. ຄວາມຈິງແລ້ວແມ່ນວ່າໃນການປະຕິບັດສຸດທ້າຍຂ້າພະເຈົ້າໄດ້ຕັດປັດໃຈທັງຫມົດທີ່ສົ່ງຜົນກະທົບຕໍ່ການປະຕິບັດແລະເຮັດໃຫ້ຜົນໄດ້ຮັບບໍ່ມີສຽງ.

PPS: ຂໍຂອບໃຈກັບຜູ້ໃຊ້ Dmitry Tikhonov @0x1000000 ສໍາລັບການຄົ້ນພົບຄວາມຜິດພາດຂອງຂ້ອຍໃນການຕັ້ງຄ່າ Moq, ເຊິ່ງສົ່ງຜົນກະທົບຕໍ່ການວັດແທກຄັ້ງທໍາອິດ. ຖ້າຜູ້ອ່ານຄົນໃດມີກຳມະສິດພຽງພໍ, ກະລຸນາກົດ Like. ຜູ້ຊາຍຢຸດເຊົາ, ຜູ້ຊາຍອ່ານ, ຜູ້ຊາຍກວດເບິ່ງສອງຄັ້ງແລະຊີ້ໃຫ້ເຫັນຄວາມຜິດພາດ. ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ນີ້​ແມ່ນ​ມີ​ຄ່າ​ຄວນ​ຂອງ​ການ​ເຄົາ​ລົບ​ແລະ​ເຫັນ​ອົກ​ເຫັນ​ໃຈ.

PPPS: ຂໍຂອບໃຈກັບຜູ້ອ່ານທີ່ລະມັດລະວັງທີ່ໄດ້ລົງລຸ່ມຂອງແບບແລະການອອກແບບ. ຂ້າພະເຈົ້າສໍາລັບຄວາມເປັນເອກະພາບແລະຄວາມສະດວກສະບາຍ. ການທູດຂອງການນໍາສະເຫນີເຮັດໃຫ້ມີຄວາມປາດຖະຫນາຫຼາຍ, ແຕ່ຂ້າພະເຈົ້າເອົາຄໍາວິຈານເຂົ້າໄປໃນບັນຊີ. ຂ້ອຍຂໍ projectile.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com