2011-10-14 14 views
18

मैंने इसे कई बार पढ़ा है कि हास्केल में आलसी मूल्यांकन कभी-कभी अंतरिक्ष लीक का कारण बन सकता है। किस प्रकार का कोड स्पेस लीक का कारण बन सकता है? उन्हें कैसे पहचानें? और उनसे बचने के लिए प्रोग्रामर के हिस्से पर क्या सावधानी बरतनी चाहिए?हास्केल में स्पेस लीक

+7

एडवर्ड जेड यांग के [स्पेस लीक चिड़ियाघर] (http://blog.ezyang.com/2011/05/space-leak-zoo/) पर एक नज़र डालें। –

उत्तर

12

आपको शायद कई उत्तर मिलेंगे, यह एक है, मुझे कुछ 'असली दुनिया' एप्लिकेशन करने का प्रयास करते समय सामना करना पड़ा है। मैं डेटा को पास करने के लिए मल्टीथ्रेडिंग और कुछ एमवीआर का उपयोग कर रहा था (एमवीआर लॉक की गई साझा मेमोरी की तरह कुछ है)। मेरे विशिष्ट पैटर्न था:

a <- takeMVar mvar 
putMVar mvar (a + 1) 

और फिर, बस कभी कभी, जब एक उचित हालत मैं की तरह कुछ किया हुआ:

a <- takeMVar mvar 
when (a > 10) .... 

समस्या यह है कि MVAr की सामग्री अनिवार्य रूप से किया गया है (0 + 1 + 1 + 1 + ....) ... जो 100k की तरह संख्याओं के लिए काफी गहन था ... इस प्रकार की समस्या मेरे कोड में काफी व्यापक थी; दुर्भाग्यवश मल्टीथ्रेडिंग अनुप्रयोगों के लिए ऐसी समस्याओं में शामिल होना बहुत आसान है।

खोज रहा है ... क्या मैं मोड कि, स्मृति की खपत के बारे में शुरू करने और विभिन्न धागे को रोकने और अगर स्मृति पदचिह्न स्थिर है या नहीं देख डेटा का उत्पादन में Haskell ...

Anotomy of a thunk leak (with instructions how to debug it)

शुरू हो गया था था एक उदाहरण: Thunk memory leak as a result of map function

4

बड़े डेटा संरचनाओं पर पुनरावृत्ति करते समय मैंने इस समस्या में भाग लिया है। निर्मित थंक्स बहुत अधिक हो जाते हैं और फिर आपको एक स्पेस रिसाव मिलती है।

हास्केल में, आपको अंतरिक्ष रिसाव में दौड़ने की संभावना के बारे में लगातार जागरूक होने की आवश्यकता है। चूंकि पुनरावृत्ति मौजूद नहीं है, मूल रूप से किसी भी पुनरावर्ती कार्य में अंतरिक्ष रिसाव उत्पन्न करने की क्षमता होती है।

इस समस्या से बचने के लिए, पुनरावर्ती कार्यों को याद रखें, या उन्हें फिर से वर्णित करें।

संबंधित मुद्दे