ການຈັດສັນຢູ່ໃນ Stack

ເປັນ​ຫຍັງ​ການ​ຈັດ​ແບ່ງ Stack ຍັງ​ເປັນ​ເລື່ອງ​ຢູ່​ໃນ​ວິ​ສະ​ວະ​ກໍາ​ຊອບ​ແວ​ທີ່​ທັນ​ສະ​ໄຫມ

ທຸກຄັ້ງທີ່ແອັບພລິເຄຊັນຂອງທ່ານປະມວນຜົນຄຳຮ້ອງຂໍ, ສ້າງຕົວແປ ຫຼືເອີ້ນຟັງຊັນໃດໜຶ່ງ, ການຕັດສິນໃຈທີ່ງຽບໆຈະຖືກເຮັດຢູ່ເບື້ອງຫຼັງ: ຂໍ້ມູນນີ້ຄວນຢູ່ໃນຄວາມຊົງຈຳຢູ່ໃສ? ເປັນເວລາຫຼາຍທົດສະວັດ, ການຈັດສັນ stack ເປັນໜຶ່ງໃນຍຸດທະສາດຄວາມຊົງຈຳທີ່ຄາດເດົາໄດ້ໄວທີ່ສຸດທີ່ມີໃຫ້ນັກຂຽນໂປຣແກຣມ - ແຕ່ມັນຍັງມີຄວາມເຂົ້າໃຈຜິດຢ່າງກວ້າງຂວາງ. ໃນຍຸກຂອງ runtimes ທີ່ມີການຄຸ້ມຄອງ, ເຄື່ອງເກັບຂີ້ເຫຍື້ອ, ແລະສະຖາປັດຕະຍະກໍາພື້ນເມືອງ cloud, ຄວາມເຂົ້າໃຈວິທີການແລະເວລາທີ່ຈະຈັດສັນໃນ stack ສາມາດຫມາຍຄວາມວ່າຄວາມແຕກຕ່າງລະຫວ່າງແອັບພລິເຄຊັນທີ່ຈັດການກັບຜູ້ໃຊ້ 10,000 ຄົນພ້ອມໆກັນແລະຫນຶ່ງທີ່ buckles ຕ່ໍາກວ່າ 500. ທີ່ Mewayz, ບ່ອນທີ່ເວທີຂອງພວກເຮົາໃຫ້ບໍລິການຫຼາຍກວ່າ 138,000 ທຸລະກິດທີ່ມີ 207 ຫນ່ວຍຄວາມຈໍາທີ່ປະສົມປະສານທຸກໂມດູນ.

Stack ທຽບກັບ Heap: ການປິດການຄ້າຂັ້ນພື້ນຖານ

ໜ່ວຍຄວາມຈຳໃນສະພາບແວດລ້ອມການຂຽນໂປລແກລມສ່ວນໃຫຍ່ຖືກແບ່ງອອກເປັນສອງຂົງເຂດຕົ້ນຕໍ: stack ແລະ heap. stack ດໍາເນີນການເປັນໂຄງສ້າງຂໍ້ມູນສຸດທ້າຍ, ອອກທໍາອິດ (LIFO). ເມື່ອຟັງຊັນຖືກເອີ້ນ, "ກອບ" ໃໝ່ຈະຖືກຍູ້ໃສ່ stack ທີ່ມີຕົວແປທ້ອງຖິ່ນ, ທີ່ຢູ່ກັບຄືນ, ແລະຕົວກໍານົດການຟັງຊັນ. ເມື່ອຟັງຊັນນັ້ນກັບຄືນມາ, ເຟຣມທັງໝົດຈະຖືກປິດທັນທີ. ບໍ່ມີການຄົ້ນຫາ, ບໍ່ມີບັນຊີ, ບໍ່ມີການແບ່ງສ່ວນ — ພຽງແຕ່ການປັບຕົວຊີ້ອັນດຽວ.

ໃນທາງກົງກັນຂ້າມ, heap ແມ່ນກຸ່ມຄວາມຊົງຈຳຂະໜາດໃຫຍ່ທີ່ການຈັດສັນແລະການຈັດສັນສາມາດເກີດຂຶ້ນໄດ້ໃນທຸກລຳດັບ. ຄວາມຍືດຫຍຸ່ນນີ້ມີຄ່າໃຊ້ຈ່າຍ: ຜູ້ຈັດສັນຕ້ອງຕິດຕາມວ່າບລັອກໃດແມ່ນບໍ່ເສຍຄ່າ, ຈັດການການແຕກແຍກ, ແລະໃນຫຼາຍພາສາ, ອີງໃສ່ຕົວເກັບຂີ້ເຫຍື້ອເພື່ອເກັບຄືນຄວາມຊົງຈໍາທີ່ບໍ່ໄດ້ໃຊ້. ການຈັດສັນ heap ໃນໂປຣແກມ C ປົກກະຕິໃຊ້ເວລາປະມານ 10 ຫາ 20 ເວລາດົນກວ່າການຈັດສັນ stack. ໃນພາສາທີ່ເກັບຂີ້ເຫຍື້ອເຊັ່ນ Java ຫຼື C#, ຄ່າຜ່ານຫົວສາມາດສູງຍິ່ງຂຶ້ນເມື່ອການຢຸດການເກັບມ້ຽນຖືກປັດໄຈໃນ.

ການ​ເຂົ້າ​ໃຈ​ການ​ແລກປ່ຽນ​ນີ້​ບໍ່​ແມ່ນ​ພຽງ​ແຕ່​ທາງ​ວິຊາ​ການ. ເມື່ອທ່ານກໍາລັງສ້າງຊອບແວທີ່ປະມວນຜົນຫຼາຍພັນທຸລະກໍາຕໍ່ວິນາທີ — ບໍ່ວ່າຈະເປັນເຄື່ອງຈັກໃນການອອກໃບແຈ້ງໜີ້, ແຜງໜ້າປັດການວິເຄາະແບບສົດໆ ຫຼື CRM ການຈັດການການນໍາເຂົ້າການຕິດຕໍ່ຫຼາຍ – ການເລືອກຍຸດທະສາດການຈັດສັນທີ່ເຫມາະສົມສໍາລັບເສັ້ນທາງຮ້ອນສົ່ງຜົນກະທົບໂດຍກົງຕໍ່ເວລາຕອບສະຫນອງ ແລະຄ່າໃຊ້ຈ່າຍໃນໂຄງສ້າງພື້ນຖານ.

ການຈັດສັນ Stack ເຮັດວຽກແນວໃດ

ໃນ​ລະ​ດັບ​ຮາດ​ແວ, ສະ​ຖາ​ປັດ​ຕະ​ຍະ​ກຳ​ຂອງ​ໂປຣ​ເຊ​ສ​ເຊີ​ສ່ວນ​ໃຫຍ່​ຈະ​ກຳ​ນົດ​ການ​ຈົດ​ທະ​ບຽນ (ຕົວ​ຊີ້​ຕົວ​ຊີ້) ເພື່ອ​ຕິດ​ຕາມ​ຕົວ​ຊີ້​ເທິງ​ໃນ​ປັດ​ຈຸ​ບັນ. ການຈັດສັນໜ່ວຍຄວາມຈຳໃນ stack ແມ່ນງ່າຍດາຍຄືກັບການຫຼຸດຕົວຊີ້ນີ້ລົງດ້ວຍຈຳນວນໄບຕ໌ທີ່ຕ້ອງການ. Deallocation ແມ່ນປີ້ນກັບກັນ: ເພີ່ມຕົວຊີ້. ບໍ່ມີສ່ວນຫົວ metadata, ບໍ່ມີລາຍຊື່ຟຣີ, ບໍ່ມີການລວມຕົວຂອງບລັອກທີ່ຢູ່ຕິດກັນ. ອັນນີ້ຄືເຫດຜົນການຈັດສັນ stack ມັກຈະຖືກອະທິບາຍວ່າມີ O(1) ປະສິດທິພາບຄົງທີ່ກັບ overhead ທີ່ລະເລີຍ.

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

ຄວາມເຂົ້າໃຈສຳຄັນ: ການຈັດສັນ stack ບໍ່ພຽງແຕ່ໄວເທົ່ານັ້ນ — ມັນສາມາດຄາດເດົາໄດ້. ໃນລະບົບການປະຕິບັດທີ່ສໍາຄັນ, ການຄາດເດົາມັກຈະມີຄວາມສໍາຄັນຫຼາຍກ່ວາຄວາມໄວດິບ. ຟັງຊັນທີ່ເຮັດສຳເລັດຢ່າງຕໍ່ເນື່ອງໃນ 2 ໄມໂຄວິນາທີແມ່ນມີຄ່າຫຼາຍກວ່າໜຶ່ງທີ່ສະເລ່ຍ 1 ໄມໂຄວິນາທີ ແຕ່ບາງເທື່ອຈະເພີ່ມຂຶ້ນເປັນ 50 ໄມໂຄວິນາທີເນື່ອງຈາກການຢຸດເກັບຂີ້ເຫຍື້ອຊົ່ວຄາວ.

ເວລາໃດທີ່ມັກການຈັດສັນ Stack

ບໍ່ແມ່ນຂໍ້ມູນທຸກອັນຢູ່ໃນ stack. ຫນ່ວຍຄວາມຈໍາ stack ແມ່ນຈໍາກັດ (ໂດຍປົກກະຕິລະຫວ່າງ 1 MB ຫາ 8 MB ຕໍ່ຫົວຂໍ້, ຂຶ້ນກັບລະບົບປະຕິບັດການ), ແລະຂໍ້ມູນທີ່ຈັດສັນຢູ່ໃນ stack ບໍ່ສາມາດໃຊ້ຊີວິດຂອງຫນ້າທີ່ສ້າງມັນ. ແນວໃດກໍ່ຕາມ, ມີສະຖານະການທີ່ຈະແຈ້ງທີ່ການຈັດສັນ stack ເປັນທາງເລືອກທີ່ດີກວ່າ.

• ຕົວແປທ້ອງຖິ່ນທີ່ມີອາຍຸສັ້ນ: ໂຕນັບ, ຕົວເກັບສະສົມ, ບັຟເຟີຊົ່ວຄາວພາຍໃຕ້ສອງສາມກິໂລໄບ, ແລະດັດຊະນີວົງແມ່ນເໝາະສົມຕາມທໍາມະຊາດສໍາລັບ stack. ພວກມັນຖືກສ້າງຂື້ນ, ໃຊ້, ແລະຍົກເລີກພາຍໃນຂອບເຂດຟັງຊັນດຽວ.
• ໂຄງສ້າງຂໍ້ມູນຂະໜາດຄົງທີ່: Arrays ທີ່ມີຂະໜາດເວລາລວບລວມທີ່ຮູ້ຈັກ, ໂຄງສ້າງຂະໜາດນ້ອຍ ແລະປະເພດມູນຄ່າສາມາດຖືກວາງໃສ່ stack ໄດ້ໂດຍບໍ່ມີຄວາມສ່ຽງຕໍ່ການລົ້ນ. buffer 256-byte ສໍາລັບການຈັດຮູບແບບວັນທີ string ເປັນຜູ້ສະຫມັກທີ່ສົມບູນແບບ.
• Performance-critical inner loops: ເມື່ອຟັງຊັນໃດໜຶ່ງຖືກເອີ້ນຫຼາຍລ້ານເທື່ອຕໍ່ວິນາທີ — ເຊັ່ນ: ເຄື່ອງຈັກການຄຳນວນລາຄາທີ່ເຮັດຊໍ້າຄືນໃນລາຍການສິນຄ້າ — ການກໍາຈັດການຈັດສັນ heap ຢູ່ໃນສ່ວນຂອງ loop ສາມາດສົ່ງຜົນໃຫ້ມີການປັບປຸງຜ່ານ 3x ຫາ 10x.
• ເສັ້ນທາງທີ່ອ່ອນໄຫວຕາມເວລາຈິງ ຫຼື latency-sensitive: ການປະມວນຜົນການຈ່າຍເງິນ, ການອັບເດດ dashboard ສົດໆ ແລະການແຈ້ງເຕືອນການສົ່ງຜົນປະໂຫຍດທັງໝົດຈາກການຫຼີກລ່ຽງການຢຸດເກັບຂີ້ເຫຍື້ອທີ່ບໍ່ໄດ້ກໍານົດໄວ້ຊົ່ວຄາວ.
• ສູດ​ການ​ຄິດ​ຄືນ​ໃໝ່​ທີ່​ມີ​ຂອບ​ເຂດ​ຄວາມ​ເລິກ: ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ສາ​ມາດ​ຮັບ​ປະ​ກັນ​ຄວາມ​ເລິກ​ການ​ເອີ້ນ​ຄືນ​ຢູ່​ພາຍ​ໃນ​ຂອບ​ເຂດ​ທີ່​ປອດ​ໄພ, ເຟຣມ​ທີ່​ຈັດ​ສັນ​ຊ້ອນ​ກັນ​ຈະ​ເຮັດ​ໃຫ້​ໜ້າ​ທີ່​ການ​ຊ້ຳ​ຄືນ​ໄວ ແລະ​ງ່າຍ.

ໃນ​ພາກ​ປະ​ຕິ​ບັດ, compilers ທັນ​ສະ​ໄຫມ​ແມ່ນ​ດີ​ທີ່​ຫນ້າ​ສັງ​ເກດ​ໃນ​ການ​ປັບ​ປຸງ​ການ​ນໍາ​ໃຊ້ stack. ເຕັກນິກເຊັ່ນ: ການວິເຄາະການຫລົບຫນີໃນ Go ແລະ JIT compiler ຂອງ Java ສາມາດຍ້າຍການຈັດສັນ heap ໄປ stack ໂດຍອັດຕະໂນມັດເມື່ອ compiler ພິສູດວ່າຂໍ້ມູນບໍ່ໄດ້ຫນີຂອບເຂດຫນ້າທີ່. ການເຂົ້າໃຈການເພີ່ມປະສິດທິພາບເຫຼົ່ານີ້ຊ່ວຍໃຫ້ທ່ານຂຽນລະຫັດທີ່ສະອາດຂຶ້ນໃນຂະນະທີ່ຍັງໄດ້ຮັບຜົນປະໂຫຍດຈາກການປະຕິບັດ stack.

ໄພອັນຕະລາຍທົ່ວໄປ ແລະວິທີຫຼີກເວັ້ນພວກມັນ

ຂໍ້ບົກພ່ອງທີ່ກ່ຽວຂ້ອງກັບ stack ທີ່ມີຊື່ສຽງທີ່ສຸດແມ່ນ stack overflow — ການຈັດສັນຂໍ້ມູນຫຼາຍກວ່າ stack ສາມາດເກັບໄດ້, ໂດຍປົກກະຕິໂດຍຜ່ານການ recursion unbounded ຫຼື array ທ້ອງຖິ່ນຂະຫນາດໃຫຍ່ເກີນໄປ. ໃນສະພາບແວດລ້ອມການຜະລິດ, stack overflow ປົກກະຕິແລ້ວ crashes thread ຫຼືຂະບວນການທັງຫມົດທີ່ບໍ່ມີເສັ້ນທາງການຟື້ນຕົວ graceful. ນີ້​ຄື​ເຫດຜົນ​ທີ່​ກອບ​ວຽກ​ແລະ​ລະ​ບົບ​ປະ​ຕິ​ບັດ​ການ​ວາງ​ຂໍ້​ຈໍາ​ກັດ​ຂະ​ຫນາດ stack.

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

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

ການຈັດສັນສະເຕກໃນທົ່ວພາສາ ແລະກອບວຽກ

ພາສາການຂຽນໂປລແກລມທີ່ແຕກຕ່າງກັນຈັດການການຈັດແບ່ງ stack ດ້ວຍລະດັບຄວາມໂປ່ງໃສທີ່ແຕກຕ່າງກັນ. ໃນ C ແລະ C ++, ໂປລແກລມມີການຄວບຄຸມທີ່ຊັດເຈນ: ຕົວແປທ້ອງຖິ່ນໄປຢູ່ໃນ stack, ແລະ malloc ຫຼື new ເອົາຂໍ້ມູນໃສ່ໃນ heap. ໃນ Go, compiler ປະຕິບັດການວິເຄາະ escape ເພື່ອຕັດສິນໃຈອັດຕະໂນມັດ, ແລະ goroutines ເລີ່ມຕົ້ນດ້ວຍ stacks 2 KB ນ້ອຍໆທີ່ເຕີບໂຕແບບເຄື່ອນໄຫວ - ເປັນການແກ້ໄຂທີ່ສະຫງ່າງາມທີ່ສົມດຸນຄວາມປອດໄພກັບການປະຕິບັດ. PHP, ກອບການເພີ່ມປະສິດທິພາບຂອງພາສາເຊັ່ນ Laravel, ຈັດສັນຄ່າສ່ວນໃຫຍ່ໂດຍຜ່ານຕົວຈັດການຫນ່ວຍຄວາມຈໍາ Zend Engine ພາຍໃນຂອງມັນ, ແຕ່ການເຂົ້າໃຈຫຼັກການພື້ນຖານຊ່ວຍໃຫ້ນັກພັດທະນາຂຽນລະຫັດທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນເຖິງແມ່ນວ່າຢູ່ໃນລະດັບຄໍາຮ້ອງສະຫມັກ.

ສຳລັບທີມສ້າງແພລດຟອມທີ່ຊັບຊ້ອນ — ຄືກັບທີມວິສະວະກອນຢູ່ Mewayz, ບ່ອນທີ່ການຮ້ອງຂໍດຽວອາດຈະຂ້າມຜ່ານ CRM logic, ການຄິດໄລ່ໃບແຈ້ງໜີ້, ການຄິດໄລ່ພາສີເງິນເດືອນ, ແລະການລວບລວມການວິເຄາະ — ການຕັດສິນໃຈຂັ້ນຕ່ໍາເຫຼົ່ານີ້ປະສົມກັນ. ເມື່ອ 207 ໂມດູນແບ່ງປັນເວລາແລ່ນ, ການຫຼຸດຜ່ອນການຈັດສັນຫນ່ວຍຄວາມຈໍາຕໍ່ຄໍາຮ້ອງຂໍເຖິງແມ່ນ 15% ສາມາດແປເປັນການຫຼຸດລົງທີ່ມີຄວາມຫມາຍຂອງຄ່າໃຊ້ຈ່າຍຂອງເຄື່ອງແມ່ຂ່າຍແລະການປັບປຸງທີ່ສາມາດວັດແທກໄດ້ໃນເວລາຕອບສະຫນອງສໍາລັບຜູ້ໃຊ້ສຸດທ້າຍທີ່ຈັດການທຸລະກິດຂອງເຂົາເຈົ້າຢູ່ໃນເວທີ.

JavaScript ແລະ TypeScript, ເຊິ່ງໃຊ້ພະລັງງານສ່ວນໜ້າ ແລະ backends Node.js ທີ່ທັນສະໄຫມທີ່ສຸດ, ອີງໃສ່ຕົວເກັບຂີ້ເຫຍື້ອຂອງເຄື່ອງຈັກ V8 ສໍາລັບການຄຸ້ມຄອງຄວາມຊົງຈໍາ. ນັກພັດທະນາບໍ່ສາມາດຈັດສັນໂດຍກົງໃສ່ stack ໄດ້, ແຕ່ການເພີ່ມປະສິດທິພາບຂອງ compiler (TurboFan) ຂອງ V8 ປະຕິບັດການຈັດສັນ stack ພາຍໃນສໍາລັບມູນຄ່າທີ່ມັນສາມາດພິສູດໄດ້ວ່າມີອາຍຸສັ້ນ. ການຂຽນຟັງຊັນນ້ອຍໆ, ບໍລິສຸດກັບຕົວແປທ້ອງຖິ່ນເຮັດໃຫ້ເຄື່ອງຈັກມີໂອກາດທີ່ດີທີ່ສຸດທີ່ຈະນໍາໃຊ້ການເພີ່ມປະສິດທິພາບເຫຼົ່ານີ້.

ຍຸດທະສາດການປະຕິບັດເພື່ອຫຼຸດຜ່ອນຄວາມກົດດັນຂອງ Heap

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

1. ມັກປະເພດມູນຄ່າຫຼາຍກວ່າປະເພດອ້າງອີງ ບ່ອນທີ່ພາສາສະຫນັບສະຫນູນພວກມັນ. ໃນ C#, ການໃຊ້ struct ແທນ class ສໍາລັບວັດຖຸນ້ອຍໆທີ່ສ້າງຂຶ້ນເລື້ອຍໆເຮັດໃຫ້ພວກມັນຢູ່ໃນ stack. ໃນ Go, ການຖ່າຍທອດໂຄງສ້າງຂະໜາດນ້ອຍໂດຍຄ່າຫຼາຍກວ່າຕົວຊີ້ຈະບັນລຸຜົນຄືກັນ.
2. ຫຼີກ​ລ້ຽງ​ການ​ຈັດ​ສັນ​ຢູ່​ພາຍ​ໃນ​ວົງ​ການ​ທີ່​ເຄັ່ງ​ຄັດ. ຖ້າທ່ານຕ້ອງການ slice ຫຼື array ຊົ່ວຄາວພາຍໃນ loop ທີ່ແລ່ນ 100,000 ເທື່ອ, ຈັດສັນມັນຫນຶ່ງຄັ້ງກ່ອນ loop ແລະຕັ້ງມັນຄືນໃຫມ່ໃນແຕ່ລະຄັ້ງ.
3. ໃຊ້ການລວມວັດຖຸສໍາລັບວັດຖຸທີ່ສ້າງຂຶ້ນເລື້ອຍໆ ແລະຖືກທໍາລາຍ. ຖານການເຊື່ອມຕໍ່ຖານຂໍ້ມູນເປັນຕົວຢ່າງຄລາສສິກ, ແຕ່ຮູບແບບດັ່ງກ່າວໃຊ້ເທົ່າທຽມກັນກັບວັດຖຸຄໍາຮ້ອງຂໍ HTTP, serialization buffers ແລະໂຄງສ້າງບໍລິບົດການຄິດໄລ່.
4. ໂປຣໄຟລ໌ກ່ອນທີ່ຈະເພີ່ມປະສິດທິພາບ. ເຄື່ອງມືເຊັ່ນ: Go's pprof, Java's async-profiler, ຫຼື PHP's Blackfire ສາມາດລະບຸໄດ້ແນ່ນອນວ່າການຈັດສັນເກີດຂຶ້ນຢູ່ໃສ. ການເພີ່ມປະສິດທິພາບໂດຍບໍ່ມີການສ້າງຂໍ້ມູນໂປຣໄຟລ໌ມີຄວາມສ່ຽງທີ່ຈະໃຊ້ຄວາມພະຍາຍາມໃນເສັ້ນທາງເຢັນທີ່ບໍ່ຄ່ອຍຈະປະຕິບັດໄດ້.
5. Leverage arena allocators for batch operations. ໃນເວລາປະມວນຜົນ batch ຂອງ records — ເຊັ່ນ: ການສ້າງ 500 invoices ຫຼື import 10,000 contacts — a arena allocator grabblock of large single memory and parcels out with the stack-like speeds, then frees the whole blocks at once.li.