มันจะมีประสิทธิภาพมากขึ้นสำหรับระบบโดยทั่วไปที่จะทำอะไรกับ Stacks และเพียงแค่ใช้ Heap สำหรับการจัดการหน่วยความจำ

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

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

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

การกำจัดสแต็คอย่างสมบูรณ์เพื่อลดความซับซ้อนของภาษาการเขียนโปรแกรมเป็นวิธีที่ผิด IMO - วิธีที่ดีกว่าคือการแยกความแตกต่างออกไปให้คอมไพเลอร์คิดว่าควรใช้หน่วยความจำประเภทใดในขณะที่โปรแกรมเมอร์ ระดับการสร้างที่ใกล้เคียงกับที่มนุษย์คิด - และในความเป็นจริงภาษาระดับสูงเช่น C #, Java, Python และอื่น ๆ ทำสิ่งนี้อย่างแน่นอน พวกเขามีไวยากรณ์ที่เหมือนกันเกือบจะสำหรับวัตถุที่ได้รับการจัดสรรฮีปและแบบดั้งเดิมที่จัดสรรสแต็ก ('ประเภทการอ้างอิง' กับ 'ประเภทค่า' ใน. NET lingo) ทั้งโปร่งใสหรือมีความแตกต่างการทำงานเล็กน้อยซึ่งคุณต้องเข้าใจในการใช้ภาษา ถูกต้อง (แต่คุณไม่จำเป็นต้องรู้ว่า stack และ heap ทำงานอย่างไรภายใน)

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

ไม่

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

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

การออกกำลังกายทางเลือกนั้น

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

ทางเลือก

มีภาษาอื่น ๆ ที่ต้องการที่เก็บข้อมูลสำหรับแต่ละวัตถุที่สร้างขึ้นบนฮีป มันค่อนข้างช้าเช่นที่มันประนีประนอมการออกแบบ (โปรแกรมโลกแห่งความจริง) ในทางที่เลวร้ายยิ่งกว่าต้องเรียนรู้ทั้งสอง (IMO)

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

แล้วเพื่อความเรียบง่ายและแม้ว่าเราจะสูญเสียประสิทธิภาพเล็กน้อยไปกับปริมาณงานบางอย่างมันจะดีกว่าไหมที่จะไปกับมาตรฐานเดียว (เช่นกอง)?

ที่จริงแล้วประสิทธิภาพการทำงานน่าจะมีมาก!

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

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

Simula ใช้กองเพื่อทุกสิ่ง วางทุกอย่างบนกองเสมอเจือจางอีกหนึ่งระดับของความร้ายสำหรับตัวแปรท้องถิ่นและมันทำให้ความดันเพิ่มเติมเกี่ยวกับขยะสะสม (คุณต้องคำนึงว่านักสะสมขยะจริงๆดูดกลับมาแล้ว) ส่วนหนึ่งเป็นสาเหตุที่ Bjarne คิดค้น C ++

สแต็คมีประสิทธิภาพอย่างมากสำหรับข้อมูล LIFO เช่น meta-data ที่เกี่ยวข้องกับการเรียกใช้ฟังก์ชันเป็นต้น สแต็กยังใช้ประโยชน์จากคุณสมบัติการออกแบบโดยธรรมชาติของ CPU เนื่องจากประสิทธิภาพในระดับนี้เป็นพื้นฐานของทุกสิ่งทุกอย่างในกระบวนการการที่ "น้อย" ในระดับนั้นจะเผยแพร่อย่างกว้างขวาง นอกจากนี้หน่วยความจำฮีปสามารถเคลื่อนย้ายได้โดยระบบปฏิบัติการซึ่งจะเป็นอันตรายต่อสแต็ก ในขณะที่สแต็กสามารถนำไปใช้ในฮีปได้ แต่ก็ต้องมีค่าใช้จ่ายที่จะส่งผลกระทบต่อกระบวนการทุกชิ้นในระดับที่ละเอียดที่สุด

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

เนื่องจากการจัดสรรสแต็กนั้นแทบจะไม่มีเวลาเลยการจัดสรรแม้ในฮีปที่มีประสิทธิภาพมากจะเป็น 100k (หากไม่ใช่ 1M +) ของเวลาที่ช้ากว่า

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

แน่นอนว่าถ้าฮาร์ดแวร์เร็วพอคุณสามารถเขียนแอปพลิเคชันที่ใช้เฉพาะฮีป แต่ตอนนี้คุณสามารถเขียนแอปพลิเคชันประเภทใดถ้าคุณใช้ประโยชน์จากฮีปและใช้ฮาร์ดแวร์เดียวกัน

คุณอาจสนใจ "การรวบรวมขยะเร็ว แต่สแต็คเร็วกว่า"

http://dspace.mit.edu/bitstream/handle/1721.1/6622/AIM-1462.ps.Z

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

สแต็ก "สแต็กเฟรม" ที่จัดสรรได้ดีกว่า "สแต็กเฟรม" ที่จัดสรรโดยฮีปอย่างเด็ดขาด

กองการโทรจะทำงานกับฮีปได้อย่างไร โดยพื้นฐานแล้วคุณจะต้องจัดสรรสแต็คบนฮีปในทุกโปรแกรมดังนั้นทำไมไม่มี OS + ฮาร์ดแวร์ทำเช่นนั้นสำหรับคุณ

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

ต้องใช้ทั้งสแต็กและฮีป พวกเขาจะใช้ในสถานการณ์ที่แตกต่างกันเช่น:

1. การจัดสรรฮีปมีข้อ จำกัด ที่ sizeof (a [0]) == sizeof (a [1])
2. การจัดสรรสแต็กมีข้อ จำกัด ที่ sizeof (a) เป็นค่าคงที่เวลารวบรวม
3. การจัดสรรฮีปสามารถทำลูปกราฟและโครงสร้างข้อมูลที่ซับซ้อนได้
4. การจัดสรรสแต็กสามารถทำแผนผังขนาดเวลารวบรวม
5. กองต้องติดตามความเป็นเจ้าของ
6. การจัดสรรสแต็กและการจัดสรรคืนอัตโนมัติ
7. หน่วยความจำฮีปสามารถส่งผ่านจากขอบเขตหนึ่งไปอีกขอบเขตหนึ่งได้อย่างง่ายดายผ่านตัวชี้
8. หน่วยความจำสแต็คนั้นมีอยู่ในแต่ละฟังก์ชันและวัตถุจะต้องถูกย้ายไปยังขอบเขตด้านบนเพื่อยืดอายุการใช้งาน (หรือเก็บไว้ในวัตถุแทนที่จะเป็นฟังก์ชันสมาชิกภายใน)
9. ฮีปไม่ดีต่อประสิทธิภาพ
10. สแต็คค่อนข้างเร็ว
11. อ็อบเจ็กต์ฮีปถูกส่งคืนจากฟังก์ชันผ่านตัวชี้ที่เป็นเจ้าของ หรือ shared_ptrs
12. วัตถุสแต็กจะถูกส่งคืนจากฟังก์ชั่นผ่านการอ้างอิงที่ไม่ได้เป็นเจ้าของ
13. Heap ต้องการการจับคู่ใหม่ทุกประเภทด้วยการลบหรือลบที่ถูกต้อง []
14. วัตถุสแต็คใช้ RAII และรายการเริ่มต้นของตัวสร้าง
15. วัตถุฮีปสามารถเริ่มต้นได้ทุกจุดภายในฟังก์ชั่นและไม่สามารถใช้พารามิเตอร์คอนสตรัคเตอร์ได้
16. วัตถุสแต็กใช้พารามิเตอร์ตัวสร้างสำหรับการเริ่มต้น
17. ฮีปใช้อาร์เรย์และขนาดอาร์เรย์สามารถเปลี่ยนแปลงได้ในรันไทม์
18. สแต็คสำหรับวัตถุเดี่ยวและขนาดได้รับการแก้ไขในเวลารวบรวม

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

คอมพิวเตอร์สมัยใหม่มีหน่วยความจำแคชหลายชั้นนอกเหนือจากระบบหน่วยความจำหลักขนาดใหญ่ แต่ช้า หนึ่งสามารถเข้าถึงหน่วยความจำแคชที่เร็วที่สุดในเวลาที่จำเป็นในการอ่านหรือเขียนหนึ่งไบต์จากระบบหน่วยความจำหลัก ดังนั้นการเข้าถึงที่ตั้งหนึ่งพันครั้งจึงเร็วกว่าการเข้าถึงสถานที่อิสระ 1,000 แห่ง (หรือ 100 แห่ง) แต่ละแห่ง เนื่องจากแอปพลิเคชั่นส่วนใหญ่จัดสรรและยกเลิกการจัดสรรหน่วยความจำขนาดเล็กจำนวนมากใกล้กับด้านบนสุดของสแต็คตำแหน่งที่อยู่ด้านบนสุดของสแต็กจะถูกใช้งานและใช้ซ้ำจำนวนมหาศาลเช่นส่วนใหญ่ (99% + ในแอปพลิเคชันทั่วไป) ของการเข้าถึงสแต็กสามารถจัดการได้โดยใช้หน่วยความจำแคช

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

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