सी / सी + + फ़ाइल I / O को वास्तव में तनाव रहित किए बिना तेजी

प्रस्तावना

दुनिया में इस तरह की एक सरल और बहुत उपयोगी उपयोगिता है - बीडेल्टा , और यह ऐसा हुआ कि इसने लंबे समय तक हमारी उत्पादन प्रक्रिया में जड़ ली (हालांकि इसका संस्करण स्थापित नहीं किया जा सका, लेकिन यह निश्चित रूप से अंतिम उपलब्ध नहीं था)। हम इसका उपयोग अपने इच्छित उद्देश्य के लिए करते हैं - बाइनरी पैच का निर्माण। यदि आप देखें कि रिपॉजिटरी में क्या है, तो यह थोड़ा दुखद है: वास्तव में, यह बहुत पहले छोड़ दिया गया था और वहां बहुत पुराना था (एक बार मेरे पूर्व सहयोगी ने वहां कई सुधार किए थे, लेकिन यह बहुत समय पहले था)। सामान्य तौर पर, मैंने इस व्यवसाय को फिर से शुरू करने का फैसला किया: मैंने कांटा किया, जो मैंने उपयोग करने की योजना नहीं बनाई थी, उसे सीमेक पर परियोजना से आगे निकल गया, "हॉट" माइक्रोफंक्शन को इनलाइन किया, स्टैक से बड़े सरणियों को हटा दिया (स्टैक और वैरिएबल-लंबाई सरणियों, जिसे मैं खुलकर "बमबारी" से)। , एक बार फिर से प्रोफाइलर को निकाल दिया - और पता चला कि लगभग 40% समय फेरीराइट पर खर्च होता है ...

तो क्या लिखने के साथ है?

इस कोड में, fwrite (मेरे विशेष परीक्षण मामले में: करीब 300 एमबी फ़ाइलों के बीच एक पैच का निर्माण, इनपुट डेटा पूरी तरह से मेमोरी में है) एक छोटे बफर के साथ लाखों बार कहा जाता है। जाहिर है, यह बात धीमी हो जाएगी, और इसलिए मैं किसी भी तरह इस अपमान को प्रभावित करना चाहूंगा। किसी भी प्रकार के डेटा स्रोतों, अतुल्यकालिक इनपुट-आउटपुट को लागू करने की कोई इच्छा नहीं है, मैं एक समाधान आसान खोजना चाहता था। पहली बात जो दिमाग में आई वह थी बफर का आकार बढ़ाना

setvbuf(file, nullptr, _IOFBF, 64* 1024) 

लेकिन मुझे परिणाम में महत्वपूर्ण सुधार नहीं मिला (अब fwrite का समय लगभग 37% था) - इसका मतलब यह है कि यह मामला अभी भी डिस्क में लगातार डेटा रिकॉर्डिंग में नहीं है। "हूड के तहत" को फिर से लिखना, आप देख सकते हैं कि लॉक / अनलॉक FILE संरचना इस तरह से हो रही है (छद्म कोड, सभी विश्लेषण विजुअल स्टूडियो 2017 के तहत किया गया था):

 size_t fwrite (const void *buffer, size_t size, size_t count, FILE *stream) { size_t retval = 0; _lock_str(stream); /* lock stream */ __try { retval = _fwrite_nolock(buffer, size, count, stream); } __finally { _unlock_str(stream); /* unlock stream */ } return retval; } 

प्रोफाइलर के अनुसार, _fwrite_nolock केवल 6% समय के लिए है, बाकी ओवरहेड है। मेरे विशेष मामले में, थ्रेड सेफ्टी एक स्पष्ट अतिरिक्त है, मैं इसे ffite कॉल को _fwrite_nolock से बदलकर बलिदान कर दूंगा - यहां तक ​​कि उन तर्कों के साथ भी जिन्हें मुझे स्मार्ट होने की आवश्यकता नहीं है। कुल: कई बार इस सरल हेरफेर ने परिणाम को रिकॉर्ड करने की लागत को कम कर दिया, जो मूल संस्करण में लगभग आधे समय की लागत थी। वैसे, POSIX दुनिया में एक समान कार्य है - fwrite_unlocked । आम तौर पर बोलते हुए, वही फ़्रेड के लिए जाता है। इस प्रकार, #define जोड़ी की मदद से, यदि आप आवश्यक नहीं हैं, तो आप अपने आप को बिना अनावश्यक ताले के एक क्रॉस-प्लेटफॉर्म समाधान प्राप्त कर सकते हैं (और ऐसा अक्सर होता है)।

fwrite, _fwrite_nolock, setvbuf

आइए मूल परियोजना से अमूर्त करें और एक विशिष्ट मामले का परीक्षण शुरू करें: अत्यंत छोटे भागों में एक बड़ी फ़ाइल (512 एमबी) की रिकॉर्डिंग - 1 बाइट। परीक्षण प्रणाली: AMD Ryzen 7 1700, 16 GB RAM, HDD 3.5 "7200 rpm 64 एमबी कैश, विंडोज 10 1809, बिनार 32-बिट बनाया गया था, अनुकूलन शामिल किए गए हैं, पुस्तकालय सांख्यिकीय रूप से जुड़ा हुआ है।

प्रयोग के लिए नमूना:

 #include <chrono> #include <cstdio> #include <inttypes.h> #include <memory> #ifdef _MSC_VER #define fwrite_unlocked _fwrite_nolock #endif using namespace std::chrono; int main() { std::unique_ptr<FILE, int(*)(FILE*)> file(fopen("test.bin", "wb"), fclose); if (!file) return 1; constexpr size_t TEST_BUFFER_SIZE = 256 * 1024; if (setvbuf(file.get(), nullptr, _IOFBF, TEST_BUFFER_SIZE) != 0) return 2; auto start = steady_clock::now(); const uint8_t b = 77; constexpr size_t TEST_FILE_SIZE = 512 * 1024 * 1024; for (size_t i = 0; i < TEST_FILE_SIZE; ++i) fwrite_unlocked(&b, sizeof(b), 1, file.get()); auto end = steady_clock::now(); auto interval = duration_cast<microseconds>(end - start); printf("Time: %lld\n", interval.count()); return 0; } 

चर TEST_BUFFER_SIZE होंगे, और कुछ मामलों के लिए हम fwrite_unlocked को fwrite से बदल देंगे। आइए बफर के आकार को स्पष्ट रूप से सेट किए बिना fwrite के मामले के साथ शुरू करें (setvbuf और संबंधित कोड पर टिप्पणी करें): समय 27048906 μs, गति लिखें - 18.93 एमबी / एस। अब बफर आकार को 64 Kb: समय - 25037111 μs, गति - 20.44 Mb / s पर सेट करें। अब हम बिना कॉल किए सेट _bwrite_nolock के संचालन का परीक्षण करते हैं: 7262221 ms, गति 70.5 Mb / s है!

अगला, बफर के आकार के साथ प्रयोग करें (सेटव्यूफ):



डेटा औसत 5 प्रयोगों द्वारा प्राप्त किया गया था, मैं त्रुटियों पर विचार करने के लिए बहुत आलसी था। मेरे लिए, 93 एमबी / एस जब एक नियमित एचटीडी को 1 बाइट लिखना एक बहुत अच्छा परिणाम है, तो बस इष्टतम बफर आकार (मेरे मामले में 256 केबी - बस दाएं) का चयन करें और फ़र्वाइट को _fwrite_nolock / fyite_unlocked (के साथ बदलें) यदि थ्रेड सुरक्षा की आवश्यकता नहीं है, तो निश्चित रूप से)।
इसी तरह की परिस्थितियों में भय के साथ। अब देखते हैं कि लिनक्स पर चीजें कैसे होती हैं, परीक्षण कॉन्फ़िगरेशन निम्नानुसार है: एएमडी राइज़ेन 7 1700X, 16 जीबी रैम, एचडीडी 3.5 "7200 आरपीएम 64 एमबी कैश, ओपनएसयूएसई 15 ओएस, जीसीसी 8.3.1, हम x86-64 बिनार, फ़ाइल सिस्टम का परीक्षण करेंगे ext4 परीक्षण अनुभाग इस परीक्षण में बफर आकार को स्पष्ट रूप से सेट किए बिना fwrite का परिणाम 67.6 Mb / s है, जब बफर को 256 Kb पर सेट करने की गति बढ़ कर 69.7 Mb / s हो गई है। अब हम fwrite -unlocked के लिए समान माप निकालेंगे - परिणाम क्रमशः 93.5 और 94.6 Mb / s हैं। 1 केबी से 8 एमबी तक के बफर साइज़ को कम करते हुए मुझे निम्नलिखित निष्कर्षों तक ले गए: बफर बढ़ाने से लेखन की गति बढ़ जाती है, लेकिन मेरे मामले में अंतर केवल 3 एमबी / एस था, मुझे 64 केबीपीएस और 8 बफर के बीच की गति में कोई अंतर नजर नहीं आया। इस लिनक्स मशीन पर प्राप्त आंकड़ों से, हम निम्नलिखित निष्कर्ष निकाल सकते हैं:

• fwrite_unlocked, fwrite से तेज है, लेकिन लिखने की गति में अंतर विंडोज पर उतना महान नहीं है
• लिनक्स पर बफर का आकार लिखने की गति पर महत्वपूर्ण प्रभाव के रूप में fwrite / fwrite_unlocked विंडोज के माध्यम से नहीं है

कुल मिलाकर, प्रस्तावित विधि विंडोज पर, लेकिन लिनक्स पर भी (बहुत कम सीमा तक) प्रभावी है।

अंतभाषण

इस लेख का उद्देश्य कई मामलों में एक सरल और प्रभावी विधि का वर्णन करना था (मैं पहले _fwrite_nolock / fwrite_unlocked कार्यों में नहीं आया था, वे बहुत लोकप्रिय नहीं हैं - लेकिन व्यर्थ में)। मैं सामग्री के लिए नया होने का नाटक नहीं करता, लेकिन मुझे उम्मीद है कि लेख समुदाय के लिए उपयोगी होगा।