हामीले C++ 10 मानक (र त्यसपछि C++14 मा) C++ कोडको 17 मिलियन लाइनहरू कसरी अनुवाद गर्यौं।

केहि समय पहिले (2016 को पतन मा), 1C को अर्को संस्करण को विकास को समयमा: उद्यम टेक्नोलोजी प्लेटफर्म, नयाँ मानक को समर्थन को बारे मा विकास टोली भित्र प्रश्न उठ्यो। C ++ १ हाम्रो कोड मा। नयाँ मानकमा संक्रमण, हामीले ग्रहण गरेझैं, हामीलाई धेरै कुराहरू अझ सुन्दर, सरल र भरपर्दो रूपमा लेख्न अनुमति दिनेछ, र कोडको समर्थन र मर्मतसम्भारलाई सरल बनाउनेछ। र त्यहाँ अनुवादमा असाधारण केही छैन जस्तो देखिन्छ, यदि कोड आधारको मापन र हाम्रो कोडको विशिष्ट सुविधाहरूको लागि होइन।

नजान्नेहरूका लागि, 1C:Enterprise क्रस-प्लेटफर्म व्यापार अनुप्रयोगहरूको द्रुत विकास र विभिन्न OS र DBMSs मा तिनीहरूको कार्यान्वयनको लागि रनटाइमको लागि वातावरण हो। सामान्य सर्तहरूमा, उत्पादनले समावेश गर्दछ:

• एप्लिकेसन सर्भर क्लस्टर, Windows र Linux मा चल्छ
• ग्राहक, http(हरू) वा यसको आफ्नै बाइनरी प्रोटोकल मार्फत सर्भरसँग काम गर्दै, Windows, Linux, macOS मा काम गर्दछ
• वेब ग्राहक, क्रोम, इन्टरनेट एक्सप्लोरर, माइक्रोसफ्ट एज, फायरफक्स, सफारी ब्राउजरहरूमा चलिरहेको (जाभास्क्रिप्टमा लेखिएको)
• विकास वातावरण (कन्फिगरेटर), Windows, Linux, macOS मा काम गर्दछ
• प्रशासन उपकरणहरू अनुप्रयोग सर्भरहरू, Windows, Linux, macOS मा चलाउनुहोस्
• मोबाइल ग्राहक, http(हरू) मार्फत सर्भरमा जडान गर्दै, एन्ड्रोइड, iOS, Windows चल्ने मोबाइल उपकरणहरूमा काम गर्दछ
• मोबाइल प्लेटफर्म - एन्ड्रोइड, आईओएस, विन्डोजमा चलिरहेको सिङ्क्रोनाइज गर्ने क्षमताको साथ अफलाइन मोबाइल अनुप्रयोगहरू सिर्जना गर्ने ढाँचा।
• विकास वातावरण 1C: उद्यम विकास उपकरणहरू, Java मा लेखिएको
• सर्भर अन्तरक्रिया प्रणाली

हामी सम्भव भएसम्म विभिन्न अपरेटिङ सिस्टमहरूको लागि एउटै कोड लेख्ने प्रयास गर्छौं - सर्भर कोड आधार 99% सामान्य छ, ग्राहक कोड आधार लगभग 95% छ। 1C: इन्टरप्राइज टेक्नोलोजी प्लेटफर्म मुख्य रूपमा C++ मा लेखिएको छ र अनुमानित कोड विशेषताहरू तल दिइएको छ:

• C++ कोडको १० मिलियन लाइनहरू,
• १४ हजार फाइलहरू,
• ६० हजार कक्षा,
• आधा मिलियन विधिहरू।

र यी सबै सामानहरू C++14 मा अनुवाद गर्नुपर्थ्यो। आज हामी तपाईलाई बताउनेछौं कि हामीले यो कसरी गर्यौं र हामीले प्रक्रियामा के सामना गर्यौं।

अस्वीकरण

ढिलो/छिटो कामको बारेमा तल लेखिएको सबै कुरा, (होइन) विभिन्न पुस्तकालयहरूमा मानक कक्षाहरू कार्यान्वयन गरेर ठूलो मेमोरी खपतको अर्थ एउटा कुरा हो: यो अमेरिकाको लागि सत्य हो। यो सम्भव छ कि मानक कार्यान्वयनहरू तपाईंको कार्यहरूको लागि उत्तम उपयुक्त हुनेछ। हामीले हाम्रो आफ्नै कार्यहरूबाट सुरु गर्यौं: हामीले हाम्रा ग्राहकहरूका लागि सामान्य डेटा लियौं, तिनीहरूमा विशिष्ट परिदृश्यहरू चलायौं, कार्यसम्पादन, मेमोरी खपतको मात्रा, आदि हेर्यौं, र विश्लेषण गर्‍यौं कि हामी र हाम्रा ग्राहकहरू त्यस्ता परिणामहरूबाट सन्तुष्ट छौं वा छैनौं। । र तिनीहरूले निर्भर अभिनय गरे।

हामीसँग के थियो

सुरुमा, हामीले माइक्रोसफ्ट भिजुअल स्टुडियोमा 1C:Enterprise 8 प्लेटफर्मको लागि कोड लेख्यौं। परियोजना प्रारम्भिक 2000 मा सुरु भयो र हामीसँग Windows-मात्र संस्करण थियो। स्वाभाविक रूपमा, तब देखि कोड सक्रिय रूपमा विकसित भएको छ, धेरै संयन्त्रहरू पूर्ण रूपमा पुन: लेखिएको छ। तर कोड 1998 मानक अनुसार लेखिएको थियो, र, उदाहरण को लागी, हाम्रो दायाँ कोण कोष्ठकहरु खाली ठाउँहरु द्वारा अलग गरिएको थियो ताकि संकलन सफल हुनेछ, जस्तै:

vector<vector<int> > IntV;

2006 मा, प्लेटफर्म संस्करण 8.1 को रिलीज संग, हामीले लिनक्सलाई समर्थन गर्न थाल्यौं र तेस्रो-पक्ष मानक पुस्तकालयमा स्विच गर्यौं। STLPport। संक्रमणको एउटा कारण फराकिलो लाइनहरूसँग काम गर्नु थियो। हाम्रो कोडमा, हामी std::wstring प्रयोग गर्छौं, जुन wchar_t प्रकारमा आधारित छ, भर। विन्डोजमा यसको साइज २ बाइट्स हो, र लिनक्समा डिफल्ट ४ बाइट हुन्छ। यसले ग्राहक र सर्भर बीचको हाम्रो बाइनरी प्रोटोकलहरूको असंगतताको नेतृत्व गर्‍यो, साथै विभिन्न निरन्तर डाटा। gcc विकल्पहरू प्रयोग गरेर, तपाइँ निर्दिष्ट गर्न सक्नुहुन्छ कि संकलनको क्रममा wchar_t को साइज पनि २ बाइट हो, तर तपाइँ कम्पाइलरबाट मानक पुस्तकालय प्रयोग गर्न बिर्सन सक्नुहुन्छ, किनभने यसले glibc प्रयोग गर्दछ, जुन बारीमा 2-बाइट wchar_t को लागि कम्पाइल गरिएको छ। अन्य कारणहरू मानक कक्षाहरूको राम्रो कार्यान्वयन, ह्यास तालिकाहरूको लागि समर्थन, र कन्टेनरहरू भित्र सर्ने अर्थशास्त्रको अनुकरण पनि थियो, जुन हामीले सक्रिय रूपमा प्रयोग गर्यौं। र एउटा थप कारण, जसरी तिनीहरूले अन्तिम तर कम्तिमा भने होइन, स्ट्रिङ प्रदर्शन थियो। स्ट्रिङका लागि हाम्रो आफ्नै कक्षा थियो, किनभने... हाम्रो सफ्टवेयरको विशिष्टताका कारण, स्ट्रिङ अपरेशनहरू धेरै व्यापक रूपमा प्रयोग गरिन्छ र हाम्रो लागि यो महत्त्वपूर्ण छ।

हाम्रो स्ट्रिङ प्रारम्भिक 2000 मा फिर्ता व्यक्त गरिएको स्ट्रिङ अप्टिमाइजेसन विचारहरूमा आधारित छ आन्द्रेई अलेक्जान्डरेस्कु। पछि, जब अलेक्जान्डरेस्कुले फेसबुकमा काम गरे, उनको सुझावमा, फेसबुक इन्जिनमा समान सिद्धान्तहरूमा काम गर्ने लाइन प्रयोग गरियो (पुस्तकालय हेर्नुहोस्। मूर्खता).

हाम्रो लाइनले दुई मुख्य अनुकूलन प्रविधिहरू प्रयोग गर्यो:

1. छोटो मानहरूको लागि, स्ट्रिङ वस्तुमा आन्तरिक बफर प्रयोग गरिन्छ (अतिरिक्त मेमोरी आवंटन आवश्यक पर्दैन)।
2. अन्य सबैको लागि, मेकानिक्स प्रयोग गरिन्छ प्रतिलिपिमा लेख्नुहोस्। स्ट्रिङ मान एकै ठाउँमा भण्डार गरिएको छ, र असाइनमेन्ट/परिमार्जनको क्रममा सन्दर्भ काउन्टर प्रयोग गरिन्छ।

प्लेटफर्म संकलनलाई गति दिनको लागि, हामीले हाम्रो STLPport संस्करण (जसलाई हामीले प्रयोग गरेका छैनौं) बाट स्ट्रिम कार्यान्वयन बहिष्कार गर्यौं, यसले हामीलाई लगभग 20% छिटो संकलन दियो। पछि हामीले सीमित प्रयोग गर्नुपर्‍यो बढावा। बूस्टले स्ट्रिमको भारी प्रयोग गर्दछ, विशेष गरी यसको सेवा एपीआईहरूमा (उदाहरणका लागि, लगिङको लागि), त्यसैले हामीले यसलाई स्ट्रिमको प्रयोग हटाउन परिमार्जन गर्नुपर्‍यो। यसले, बदलामा, हामीलाई बूस्टको नयाँ संस्करणहरूमा माइग्रेट गर्न गाह्रो बनायो।

तेस्रो बाटो

C++14 मानकमा सर्दा, हामीले निम्न विकल्पहरू विचार गर्यौं:

1. हामीले परिमार्जन गरेको STLPport लाई C++14 मापदण्डमा अपग्रेड गर्नुहोस्। विकल्प धेरै गाह्रो छ, किनभने ... STLPport को लागि समर्थन 2010 मा बन्द गरिएको थियो, र हामीले यसको सबै कोड आफैं निर्माण गर्नुपर्नेछ।
2. C++14 सँग मिल्दो अर्को STL कार्यान्वयनमा संक्रमण। यो अत्यधिक वांछनीय छ कि यो कार्यान्वयन Windows र Linux को लागी हो।
3. प्रत्येक OS को लागि कम्पाइल गर्दा, सम्बन्धित कम्पाइलरमा निर्मित पुस्तकालय प्रयोग गर्नुहोस्।

धेरै कामको कारण पहिलो विकल्प सिधै अस्वीकार गरियो।

हामीले केही समयको लागि दोस्रो विकल्पको बारेमा सोच्यौं; उम्मेदवार मानिन्छ libc++, तर त्यस समयमा यसले विन्डोज अन्तर्गत काम गर्दैन। विन्डोजमा libc++ पोर्ट गर्न, तपाईंले धेरै काम गर्नुपर्नेछ - उदाहरणका लागि, यी क्षेत्रहरूमा libc++ प्रयोग भएकोले थ्रेड, थ्रेड सिङ्क्रोनाइजेसन र एटोमिसिटीसँग सम्बन्धित सबै कुरा आफैंले लेख्नुहोस्। POSIX API.

र हामीले तेस्रो बाटो रोज्यौं।

संक्रमण

त्यसोभए, हामीले STLPport को प्रयोगलाई सम्बन्धित कम्पाइलरहरूको पुस्तकालयहरू (विन्डोजको लागि भिजुअल स्टुडियो 2015, लिनक्सको लागि gcc 7, macOS को लागि clang 8) प्रतिस्थापन गर्नुपर्‍यो।

सौभाग्यवश, हाम्रो कोड मुख्यतया दिशानिर्देशहरू अनुसार लेखिएको थियो र सबै प्रकारका चतुर चालहरू प्रयोग गर्दैन, त्यसैले नयाँ पुस्तकालयहरूमा माइग्रेसन अपेक्षाकृत सहज रूपमा अगाडि बढ्यो, लिपिहरूको मद्दतले टाइपहरू, वर्गहरू, नेमस्पेसहरू र स्रोतमा समावेशहरूको नामहरू प्रतिस्थापन गरियो। फाइलहरू। माइग्रेसनले 10 स्रोत फाइलहरूलाई असर गर्यो (000 मध्ये)। wchar_t लाई char14_t द्वारा प्रतिस्थापन गरिएको थियो; हामीले wchar_t को प्रयोग त्याग्न निर्णय गर्यौं, किनभने char000_t ले सबै OS मा 16 बाइटहरू लिन्छ र Windows र Linux बीचको कोड अनुकूलता बिगार्दैन।

त्यहाँ केही साना साहसिक कार्यहरू थिए। उदाहरण को लागी, STLPport मा एक पुनरावृत्ति एक तत्व को लागी एक सूचक को लागी स्पष्ट रूपमा कास्ट गर्न सकिन्छ, र हाम्रो कोड मा केहि स्थानहरुमा यो प्रयोग गरिएको थियो। नयाँ पुस्तकालयहरूमा यो गर्न सम्भव थिएन, र यी खण्डहरू विश्लेषण र म्यानुअल रूपमा पुन: लेख्नुपर्ने थियो।

त्यसैले, कोड माइग्रेसन पूरा भयो, कोड सबै अपरेटिङ सिस्टमहरूको लागि कम्पाइल गरिएको छ। यो परीक्षाको लागि समय हो।

संक्रमण पछिको परीक्षणहरूले कोडको पुरानो संस्करणको तुलनामा प्रदर्शनमा गिरावट (केही ठाउँहरूमा 20-30% सम्म) र मेमोरी खपत (10-15% सम्म) बढेको देखाएको छ। यो, विशेष गरी, मानक स्ट्रिङ को suboptimal प्रदर्शन को कारण थियो। त्यसकारण, हामीले फेरि हाम्रो आफ्नै, थोरै परिमार्जित लाइन प्रयोग गर्नुपर्‍यो।

एम्बेडेड पुस्तकालयहरूमा कन्टेनरहरूको कार्यान्वयनको एक रोचक विशेषता पनि प्रकट भएको थियो: खाली (तत्वहरू बिना) std:: नक्शा र std:: निर्मित पुस्तकालयहरू मेमोरी आवंटनबाट सेट। र कार्यान्वयन सुविधाहरूको कारण, कोडमा केही ठाउँहरूमा यस प्रकारका धेरै खाली कन्टेनरहरू सिर्जना गरिएका छन्। मानक मेमोरी कन्टेनरहरू थोरै आवंटित गरिएको छ, एक मूल तत्वको लागि, तर हाम्रो लागि यो महत्वपूर्ण भयो - धेरै परिदृश्यहरूमा, हाम्रो प्रदर्शन उल्लेखनीय रूपमा घट्यो र मेमोरी खपत बढ्यो (STLPport को तुलनामा)। त्यसकारण, हाम्रो कोडमा हामीले यी दुई प्रकारका कन्टेनरहरूलाई बिल्ट-इन पुस्तकालयहरूबाट तिनीहरूको बूस्टबाट कार्यान्वयनको साथ बदल्यौं, जहाँ यी कन्टेनरहरूमा यो सुविधा थिएन, र यसले ढिलो र मेमोरी खपत बढेको समस्या समाधान गर्‍यो।

ठूला परियोजनाहरूमा ठूला-ठूला परिवर्तनहरू पछि प्रायः हुन्छ, स्रोत कोडको पहिलो पुनरावृत्ति समस्या बिना काम गर्दैन, र यहाँ, विशेष गरी, विन्डोज कार्यान्वयनमा डिबगिङ पुनरावृत्तिहरूको लागि समर्थन काममा आयो। चरणबद्ध रूपमा हामी अगाडि बढ्यौं, र 2017 को वसन्तमा (संस्करण 8.3.11 1C:Enterprise) माइग्रेसन पूरा भयो।

परिणामहरू

C++ 14 मानकमा संक्रमणले हामीलाई लगभग 6 महिना लियो। धेरै जसो समय, एक (तर धेरै उच्च योग्य) विकासकर्ताले परियोजनामा ​​​​काम गरे, र अन्तिम चरणमा विशिष्ट क्षेत्रहरूको लागि जिम्मेवार टोलीका प्रतिनिधिहरू - UI, सर्भर क्लस्टर, विकास र प्रशासन उपकरणहरू, आदिमा सामेल भए।

ट्रान्जिसनले मानकको नवीनतम संस्करणहरूमा माइग्रेट गर्ने हाम्रो कामलाई धेरै सरल बनायो। तसर्थ, संस्करण 1C: उद्यम 8.3.14 (विकासमा, अर्को वर्षको प्रारम्भमा जारी हुने तालिका) पहिले नै मानकमा हस्तान्तरण गरिएको छ। C++17.

माइग्रेसन पछि, विकासकर्ताहरूसँग थप विकल्पहरू छन्। यदि पहिले हामीसँग STL को आफ्नै परिमार्जित संस्करण र एउटा std नेमस्पेस थियो भने, अब हामीसँग std नेमस्पेसमा निर्मित कम्पाइलर पुस्तकालयहरूबाट मानक कक्षाहरू छन्, stdx नेमस्पेसमा - हाम्रा लाइनहरू र कन्टेनरहरू हाम्रा कार्यहरूका लागि अनुकूलित छन्, बूस्टमा - बढावा को नवीनतम संस्करण। र विकासकर्ताले ती वर्गहरू प्रयोग गर्दछ जुन उसको समस्याहरू समाधान गर्न इष्टतम उपयुक्त छ।

चाल कन्स्ट्रक्टरहरूको "स्थानीय" कार्यान्वयनले पनि विकासमा मद्दत गर्दछ (कन्स्ट्रक्टरहरू सार्नुहोस्) धेरै कक्षाहरूको लागि। यदि एक क्लासमा मूभ कन्स्ट्रक्टर छ र यो क्लास कन्टेनरमा राखिएको छ भने, तब STL ले कन्टेनर भित्र तत्वहरूको प्रतिलिपि बनाउँछ (उदाहरणका लागि, जब कन्टेनर विस्तार हुन्छ र क्षमता परिवर्तन गर्न र मेमोरी पुन: आवंटन गर्न आवश्यक हुन्छ)।

टारको एक चम्चा

सायद माइग्रेसनको सबैभन्दा अप्रिय (तर आलोचनात्मक होइन) नतिजा हो कि हामीले भोल्युममा वृद्धिको सामना गरिरहेका छौं। obj फाइलहरू, र सबै मध्यवर्ती फाइलहरूसँग निर्माणको पूर्ण परिणामले 60-70 GB लिन थाल्यो। यो व्यवहार आधुनिक मानक पुस्तकालयहरूको विशिष्टताको कारण हो, जुन उत्पन्न सेवा फाइलहरूको आकारमा कम महत्वपूर्ण भएको छ। यसले कम्पाइल गरिएको अनुप्रयोगको सञ्चालनलाई असर गर्दैन, तर यसले विकासमा धेरै असुविधाहरू निम्त्याउँछ, विशेष गरी, यसले संकलन समय बढाउँछ। बिल्ड सर्भरहरू र विकासकर्ता मेसिनहरूमा नि: शुल्क डिस्क स्पेसको लागि आवश्यकताहरू पनि बढ्दै छन्। हाम्रा विकासकर्ताहरूले प्लेटफर्मका धेरै संस्करणहरूमा समानान्तर रूपमा काम गर्छन्, र सयौं गीगाबाइट मध्यवर्ती फाइलहरूले कहिलेकाहीँ तिनीहरूको काममा कठिनाइहरू सिर्जना गर्छन्। समस्या अप्रिय छ, तर गम्भीर छैन; हामीले यसको समाधान अहिलेको लागि स्थगित गरेका छौं। यसलाई समाधान गर्नका लागि हामीले प्रविधिलाई एउटा विकल्पको रूपमा हेरिरहेका छौं एकता निर्माण (विशेष गरी, गुगलले यसलाई क्रोम ब्राउजर विकास गर्दा प्रयोग गर्दछ)।

स्रोत: www.habr.com