क्या अनिर्दिष्ट एपीआई की जरूरत है?

उच्च स्तरीय प्रोग्रामिंग भाषाओं की सुंदरता क्या है?
प्रोग्रामर "यह वास्तव में कैसे कार्य करता है" के बारे में सोचना बंद कर देता है और पहाड़ को एक टन का बेहिसाब कोड देता है, जो कभी-कभी काम भी करता है, लेकिन कभी-कभी धीमा हो जाता है। इसके अलावा, अक्सर, वह इसके बारे में सोचने भी नहीं जा रहा है, क्योंकि उसके पास आवश्यक ज्ञान की कमी है (अफसोस, वे अब इसे सिखा रहे हैं)।

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

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

हालात से नहीं मिले हैं?
इतना भाग्यशाली ...



मैं ऐसे बंद टिकट के लिए विकल्पों में से एक दिखाऊंगा, जिसने एक समय में लक्ष्य एप्लिकेशन की गति को बहुत प्रभावित किया था। समस्या, निश्चित रूप से अलग थी, इसलिए मैं थोड़ा दूर हूं, लेकिन सिद्धांत रूप में यह समस्या का सार भी दर्शाता है।

मान लें कि हम एक ऐसा आवेदन लिखना चाहते हैं, जिसमें निर्दिष्ट प्रक्रिया की वर्तमान हीप्स की अप-टू-डेट सूची की आवश्यकता हो (यह क्यों कोई फर्क नहीं पड़ता, चलो एक एंटीवायरस कहते हैं :))।

सरल बनाने के लिए, हमें वर्तमान प्रक्रिया से ढेर की एक सूची मिलेगी, इसके लिए हम एक खाली कंसोल एप्लिकेशन बनाएंगे और निम्नलिखित कोड लिखेंगे:

procedure QueryProcessHeap1; var hSnapShot: THandle; HeapList: THeapList32; HeapEntry: THeapEntry32; Start: DWORD; begin Start := GetTickCount; Writeln('Heap info:'); Writeln; hSnapShot := CreateToolhelp32Snapshot(TH32CS_SNAPHEAPLIST, 0); try HeapList.dwSize := SizeOf(THeapList32); if Heap32ListFirst(hSnapShot, HeapList) then repeat HeapEntry.dwSize := SizeOf(THeapEntry32); if Heap32First(HeapEntry, GetCurrentProcessId, HeapList.th32HeapID) then repeat Writeln(Format('Heap addr: 0x%p, size: %d', [Pointer(HeapEntry.dwAddress), HeapEntry.dwBlockSize])); until not Heap32Next(HeapEntry); until not Heap32ListNext(hSnapShot, HeapList); finally CloseHandle(hSnapShot); end; Writeln; Writeln('DONE. Time elapsed: ', GetTickCount - Start); end; 

कोड असंभव से सरल है - मानक TlHelp32 फ़ंक्शन बिना तामझाम के उपयोग किए जाते हैं।
लेकिन एक अति सूक्ष्म अंतर, इसे निष्पादित करने और इसके काम के समय को देखने की कोशिश करें।

लगभग 150 मिली सेकेंड। इस तथ्य के बारे में चुटकुले कि प्रोग्रामर कंप्यूटर की बढ़ती शक्ति को गैर-अनुकूलित कोड के साथ समतल करने की कोशिश कर रहे हैं, निश्चित रूप से हास्यास्पद हैं, लेकिन ...
हमने इस डेटा को केवल अपनी प्रक्रिया से लेने की कोशिश की, लेकिन उपयोगकर्ता की मशीन पर यह कितना होगा? हां, कम से कम पचास डॉलर, और हम क्या करेंगे?

केवल प्रक्रिया हीप का अनुरोध करने में लगभग पांच-सेकंड की देरी है (मैं केवल थ्रेड प्रक्रियाओं को सूचीबद्ध करने के बारे में बात नहीं कर रहा हूं, आदि)

ठीक है, वास्तव में, लेकिन हम क्या कर सकते हैं?

हमें दोष नहीं देना है - यह है कि कैसे Heap32xxx कार्य करता है और वास्तव में, ये ब्रेक उनके कॉल में देरी के कारण होता है (यह वास्तव में ऐसा है)। और अब हम सर्वर पर अपनी सेवा के साथ बैठे हैं, प्रोसेसर संसाधनों और श्रग खा रहे हैं: "एफएसई चला गया है - बॉस।"

हमारे द्वारा बनाई गई बाधाओं को रोकने के लिए कोई भी नहीं - हम दोषी हैं।

प्रोग्रामर के पास हमेशा एक डिबगर होता है, धन्यवाद जिसके कारण आप विश्लेषण कर सकते हैं कि वास्तव में क्या हो रहा है, कम से कम सीपीयू-व्यू का उपयोग करके कॉल स्टैक का विस्तार करके।

यह देखते हुए कि मैं सॉफ़्टवेयर सुरक्षा में रुचि रखने वाले लोगों के लिए लेख लिख रहा हूं, मैं आपको यह नहीं बताऊंगा कि इसका उपयोग कैसे करें (आपको यह खुद पता होना चाहिए), इसलिए चलिए Heap32First फ़ंक्शन कॉल पर ब्रेक लगाते हैं और F7 के माध्यम से प्रोग्राम को रूट करते हैं।

कुछ दर्जन ट्रेसिंग चरणों के बाद, हम देखेंगे:



हमारे पास थोड़ा और ट्रैफ़िक होगा:



जिसके बाद हम उसी चरण को निष्पादित करेंगे, लेकिन केवल Heap32Next फ़ंक्शन के साथ।

आपको क्या लगता है कि हम वहां क्या पाते हैं?
काश - वही RtlCreateQueryDebugBuffer + RtlQueryProProcessDebugInformation और RtlDestroyQueryDebugBuffer के अंत में।

लेकिन यह पहले से ही एक अड़चन है, क्या हो रहा है? यह पता चला है कि हम में से प्रत्येक के लिए, जब tlhelp32.dll लाइब्रेरी से API फ़ंक्शन को कॉल किया जाता है , तो इन तीनों एपीआई फ़ंक्शन को वास्तव में कहा जाता है , जिनमें से पहला प्रक्रिया के बारे में जानकारी एकत्र करता है, दूसरा इसमें से केवल एक रिकॉर्ड का चयन करता है और फिर सब कुछ बंद हो जाता है। क्या यह बहुत महंगा है?

अब याद करते हैं - प्रक्रिया को सूचीबद्ध करने में हमें कितना समय लगा? 150 मिलीसेकंड? ठीक है, हाँ, क्यों नहीं, जब सभी प्रक्रिया की जानकारी प्रत्येक हील्वेड 2 नेक्स्ट कॉल के लिए फिर से एकत्र की गई थी।

हम लड़ेंगे - हम कोड लिखते हैं (मैं तुरंत आपको चेतावनी देता हूं, कोड घुटने से ऊंचा है, यह पतों के आउटपुट के साथ थोड़ा भ्रमित करता है, लेकिन यह डेमो के लिए करेगा)।

 procedure QueryProcessHeap2; var I, A: Integer; pDbgBuffer: PRtlDebugInformation; pHeapInformation: PRtlHeapInformation; pHeapEntry: PRtrHeapEntry; dwHeapStartAddr, dwAddr, dwLastSize: DWORD; hit_seg_count: Integer; Start: DWORD; begin Start := GetTickCount; Writeln('Heap info:'); Writeln; pDbgBuffer := RtlCreateQueryDebugBuffer(0, False); if pDbgBuffer <> nil then try //       if RtlQueryProcessDebugInformation(GetCurrentProcessId, RTL_QUERY_PROCESS_HEAP_SUMMARY or RTL_QUERY_PROCESS_HEAP_ENTRIES, pDbgBuffer) = 0 then begin //       pHeapInformation := @pDbgBuffer^.Heaps^.Heaps[0]; //    ... for I := 0 to pDbgBuffer^.Heaps^.NumberOfHeaps - 1 do begin //     pHeapEntry := pHeapInformation^.Entries; dwAddr := DWORD(pHeapEntry^.u.s2.FirstBlock) + pHeapInformation^.EntryOverhead; dwLastSize := 0; for A := 0 to pHeapInformation^.NumberOfEntries - 1 do begin dwHeapStartAddr := dwAddr; hit_seg_count := 0; while (pHeapEntry^.Flags and RTL_HEAP_SEGMENT) = RTL_HEAP_SEGMENT do begin //     RTL_HEAP_SEGMENT, //     dwAddr := DWORD(pHeapEntry^.u.s2.FirstBlock) + pHeapInformation^.EntryOverhead; Inc(pHeapEntry); Inc(hit_seg_count); //      if A + hit_seg_count >= Integer(pHeapInformation^.NumberOfEntries - 1) then Continue; end; //       ,     , //    +    if hit_seg_count = 0 then Inc(dwAddr, dwLastSize); Writeln(Format('Heap addr: 0x%p, size: %d', [Pointer(dwHeapStartAddr), dwAddr - dwHeapStartAddr])); //     dwLastSize := pHeapEntry^.Size; //     Inc(pHeapEntry); end; //     Inc(pHeapInformation); end; end; finally RtlDestroyQueryDebugBuffer(pDbgBuffer); end; Writeln; Writeln('DONE. Time elapsed: ', GetTickCount - Start); end; 

और हमारे यहाँ क्या है?
हालांकि, त्वरण चार गुना से अधिक है, और वास्तव में उन्होंने सिर्फ एक तिपहिया किया।

गैर-दस्तावेजी?
उसके साथ उस विदूषक, सूक्ष्मता में तल्लीन करने में संकोच नहीं करते :)
बस "जब आप कर सकते हैं" और "जब आपको ज़रूरत हो" के बीच की दूरी के बारे में मत भूलना :)

अनिर्दिष्ट कॉल का उपयोग करने के नुकसान क्या हैं?
खैर, सबसे पहले, कोई भी गारंटी नहीं दे सकता है कि इन कार्यों को कॉल करने के लिए पैरामीटर और संरचना अगले पैच के साथ नहीं बदलेगी, और वास्तव में कोई भी गारंटी नहीं दे सकता है कि वह खुद पुस्तकालय की निर्यात सूचियों में बनी रहेगी। सच है, ईमानदार होने के लिए, मुझे इस तरह के व्यवहार का सामना नहीं करना पड़ा, एक एकल फ़ंक्शन के अपवाद के साथ - AllocateAndGetTcpExTableFromStack। लेकिन इसके साथ, सामान्य तौर पर, सब कुछ किसी भी तरह से स्पष्ट नहीं हुआ, शुरू में यह विंडोज़ एक्सपी में दिखाई दिया। विस्टा के बाहर आने तक, इसे अनिर्दिष्ट माना गया था, हालांकि, विस्टा की रिलीज़ के साथ, इसे प्रलेखित किया गया था, लेकिन तुरंत Iphlpapi.dll पुस्तकालय से बाहर रखा गया था, यह लिखते हुए कि "यह फ़ंक्शन अब विंडोज विस्टा के रूप में उपयोग के लिए उपलब्ध नहीं है।"

दूसरा माइनस: किसी प्रलेखित फ़ंक्शन के प्रतिस्थापन के रूप में इस तरह के अधिक उत्पादक एनालॉग को ढूंढना हमेशा संभव नहीं होता है, और वास्तव में ज्यादातर मामलों में इसकी आवश्यकता नहीं होती है। अनुकूलन के लिए अनुकूलन सॉफ्टवेयर विकास के लिए एक बुरा पर्याप्त दृष्टिकोण है ...

स्रोत कोड यहां पाया जा सकता है: rouse.drkb.ru/blog/heap.zip

अलेक्जेंडर (Rouse_) बागेल
दिसंबर 2012