C++10 സ്റ്റാൻഡേർഡിലേക്ക് (പിന്നീട് C++14 ലേക്ക്) 17 ദശലക്ഷം C++ കോഡ് ഞങ്ങൾ എങ്ങനെയാണ് വിവർത്തനം ചെയ്തത്

കുറച്ച് കാലം മുമ്പ് (2016 അവസാനത്തോടെ), 1C: എന്റർപ്രൈസ് ടെക്നോളജി പ്ലാറ്റ്‌ഫോമിന്റെ അടുത്ത പതിപ്പ് വികസിപ്പിക്കുന്നതിനിടയിൽ, പുതിയ സ്റ്റാൻഡേർഡിനെ പിന്തുണയ്ക്കുന്നതിനെക്കുറിച്ച് ഡവലപ്‌മെന്റ് ടീമിനുള്ളിൽ ചോദ്യം ഉയർന്നു. സി ++ 14 ഞങ്ങളുടെ കോഡിൽ. ഒരു പുതിയ സ്റ്റാൻഡേർഡിലേക്കുള്ള മാറ്റം, ഞങ്ങൾ ഊഹിച്ചതുപോലെ, പല കാര്യങ്ങളും കൂടുതൽ ഗംഭീരമായും ലളിതമായും വിശ്വസനീയമായും എഴുതാൻ ഞങ്ങളെ അനുവദിക്കുകയും കോഡിന്റെ പിന്തുണയും പരിപാലനവും ലളിതമാക്കുകയും ചെയ്യും. കോഡ് ബേസിന്റെ സ്കെയിലിനും ഞങ്ങളുടെ കോഡിന്റെ പ്രത്യേക സവിശേഷതകൾക്കും വേണ്ടിയല്ലെങ്കിൽ, വിവർത്തനത്തിൽ അസാധാരണമായ ഒന്നും തന്നെയില്ലെന്ന് തോന്നുന്നു.

അറിയാത്തവർക്കായി, 1C: എന്റർപ്രൈസ് എന്നത് ക്രോസ്-പ്ലാറ്റ്ഫോം ബിസിനസ്സ് ആപ്ലിക്കേഷനുകളുടെ ദ്രുതഗതിയിലുള്ള വികസനത്തിനും വ്യത്യസ്ത OS-കളിലും DBMS-കളിലും അവയുടെ നിർവ്വഹണ സമയത്തിനുള്ള ഒരു അന്തരീക്ഷമാണ്. പൊതുവായി പറഞ്ഞാൽ, ഉൽപ്പന്നത്തിൽ ഇവ ഉൾപ്പെടുന്നു:

• ആപ്ലിക്കേഷൻ സെർവർ ക്ലസ്റ്റർ, വിൻഡോസിലും ലിനക്സിലും പ്രവർത്തിക്കുന്നു
• ഉപഭോക്താവ്, http(s) അല്ലെങ്കിൽ സ്വന്തം ബൈനറി പ്രോട്ടോക്കോൾ വഴി സെർവറുമായി പ്രവർത്തിക്കുന്നു, Windows, Linux, macOS എന്നിവയിൽ പ്രവർത്തിക്കുന്നു
• വെബ് ക്ലയന്റ്, Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari ബ്രൗസറുകളിൽ പ്രവർത്തിക്കുന്നു (JavaScript-ൽ എഴുതിയത്)
• വികസന പരിസ്ഥിതി (കോൺഫിഗറേറ്റർ), Windows, Linux, macOS എന്നിവയിൽ പ്രവർത്തിക്കുന്നു
• അഡ്മിനിസ്ട്രേഷൻ ഉപകരണങ്ങൾ ആപ്ലിക്കേഷൻ സെർവറുകൾ, Windows, Linux, macOS എന്നിവയിൽ പ്രവർത്തിക്കുക
• മൊബൈൽ ക്ലയന്റ്, http(കൾ) വഴി സെർവറിലേക്ക് കണക്റ്റുചെയ്യുന്നത്, Android, iOS, Windows പ്രവർത്തിക്കുന്ന മൊബൈൽ ഉപകരണങ്ങളിൽ പ്രവർത്തിക്കുന്നു
• മൊബൈൽ പ്ലാറ്റ്ഫോം - Android, iOS, Windows എന്നിവയിൽ പ്രവർത്തിക്കുന്ന, സമന്വയിപ്പിക്കാനുള്ള കഴിവുള്ള ഓഫ്‌ലൈൻ മൊബൈൽ ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു ചട്ടക്കൂട്
• വികസന പരിസ്ഥിതി 1C:എന്റർപ്രൈസ് ഡെവലപ്മെന്റ് ടൂളുകൾ, ജാവയിൽ എഴുതിയിരിക്കുന്നു
• സെർവർ ഇടപെടൽ സംവിധാനങ്ങൾ

കഴിയുന്നത്ര വ്യത്യസ്ത ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾക്കായി ഒരേ കോഡ് എഴുതാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു - സെർവർ കോഡ് ബേസ് 99% സാധാരണമാണ്, ക്ലയന്റ് കോഡ് ബേസ് ഏകദേശം 95% ആണ്. 1C:എന്റർപ്രൈസ് ടെക്‌നോളജി പ്ലാറ്റ്‌ഫോം പ്രാഥമികമായി C++ ൽ എഴുതിയതാണ്, കൂടാതെ ഏകദേശ കോഡ് സവിശേഷതകൾ ചുവടെ നൽകിയിരിക്കുന്നു:

• C++ കോഡിന്റെ 10 ദശലക്ഷം ലൈനുകൾ,
• 14 ആയിരം ഫയലുകൾ,
• 60 ആയിരം ക്ലാസുകൾ,
• അര ദശലക്ഷം രീതികൾ.

ഈ കാര്യങ്ങളെല്ലാം C++14-ലേക്ക് വിവർത്തനം ചെയ്യേണ്ടതുണ്ട്. ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്തുവെന്നും ഈ പ്രക്രിയയിൽ ഞങ്ങൾ എന്താണ് നേരിട്ടതെന്നും ഇന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും.

എ

സ്ലോ/ഫാസ്റ്റ് വർക്ക്, (അല്ല) വിവിധ ലൈബ്രറികളിലെ സ്റ്റാൻഡേർഡ് ക്ലാസുകൾ നടപ്പിലാക്കുന്നതിലൂടെ വലിയ മെമ്മറി ഉപഭോഗം എന്നിവയെക്കുറിച്ച് ചുവടെ എഴുതിയിരിക്കുന്നതെല്ലാം അർത്ഥമാക്കുന്നത് ഒരു കാര്യമാണ്: ഇത് ഞങ്ങൾക്ക് ശരിയാണ്. സ്റ്റാൻഡേർഡ് നിർവ്വഹണങ്ങൾ നിങ്ങളുടെ ടാസ്ക്കുകൾക്ക് ഏറ്റവും അനുയോജ്യമാകുന്നത് തികച്ചും സാദ്ധ്യമാണ്. ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം ടാസ്‌ക്കുകളിൽ നിന്നാണ് ആരംഭിച്ചത്: ഞങ്ങളുടെ ക്ലയന്റുകൾക്ക് സാധാരണമായ ഡാറ്റ ഞങ്ങൾ എടുക്കുകയും അവയിൽ സാധാരണ സാഹചര്യങ്ങൾ പ്രവർത്തിപ്പിക്കുകയും പ്രകടനം, ഉപയോഗിച്ച മെമ്മറിയുടെ അളവ് മുതലായവ പരിശോധിക്കുകയും ഞങ്ങളും ഞങ്ങളുടെ ക്ലയന്റുകളും അത്തരം ഫലങ്ങളിൽ തൃപ്തരാണോ അല്ലയോ എന്ന് വിശകലനം ചെയ്യുകയും ചെയ്തു. . അവർ അനുസരിച്ചു പ്രവർത്തിച്ചു.

നമുക്കുണ്ടായിരുന്നത്

തുടക്കത്തിൽ, ഞങ്ങൾ മൈക്രോസോഫ്റ്റ് വിഷ്വൽ സ്റ്റുഡിയോ ഉപയോഗിച്ച് 1C:Enterprise 8 പ്ലാറ്റ്‌ഫോമിനായി കോഡ് എഴുതി. 2000-കളുടെ തുടക്കത്തിൽ പ്രോജക്റ്റ് ആരംഭിച്ചു, ഞങ്ങൾക്ക് വിൻഡോസ്-മാത്രം പതിപ്പ് ഉണ്ടായിരുന്നു. സ്വാഭാവികമായും, അതിനുശേഷം കോഡ് സജീവമായി വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്, പല മെക്കാനിസങ്ങളും പൂർണ്ണമായും മാറ്റിയെഴുതിയിട്ടുണ്ട്. എന്നാൽ കോഡ് 1998 ലെ സ്റ്റാൻഡേർഡ് അനുസരിച്ചാണ് എഴുതിയത്, ഉദാഹരണത്തിന്, ഞങ്ങളുടെ വലത് ആംഗിൾ ബ്രാക്കറ്റുകൾ സ്‌പെയ്‌സുകളാൽ വേർതിരിച്ചിരിക്കുന്നു, അങ്ങനെ സമാഹാരം വിജയിക്കും, ഇതുപോലെ:

vector<vector<int> > IntV;

2006-ൽ, പ്ലാറ്റ്‌ഫോം പതിപ്പ് 8.1 പുറത്തിറങ്ങിയതോടെ, ഞങ്ങൾ ലിനക്‌സിനെ പിന്തുണയ്‌ക്കാൻ തുടങ്ങി, ഒരു മൂന്നാം കക്ഷി സ്റ്റാൻഡേർഡ് ലൈബ്രറിയിലേക്ക് മാറി. എസ്ടിഎൽ പോർട്ട്. വൈഡ് ലൈനുകളിൽ പ്രവർത്തിക്കുക എന്നതായിരുന്നു പരിവർത്തനത്തിന്റെ ഒരു കാരണം. ഞങ്ങളുടെ കോഡിൽ, ഞങ്ങൾ മുഴുവൻ wchar_t തരത്തെ അടിസ്ഥാനമാക്കിയുള്ള std::wstring ഉപയോഗിക്കുന്നു. വിൻഡോസിൽ അതിന്റെ വലുപ്പം 2 ബൈറ്റുകളും ലിനക്സിൽ സ്ഥിരസ്ഥിതി 4 ബൈറ്റുകളുമാണ്. ഇത് ക്ലയന്റും സെർവറും തമ്മിലുള്ള ഞങ്ങളുടെ ബൈനറി പ്രോട്ടോക്കോളുകളുടെ പൊരുത്തക്കേടിലേക്കും വിവിധ സ്ഥിരമായ ഡാറ്റയിലേക്കും നയിച്ചു. gcc ഓപ്‌ഷനുകൾ ഉപയോഗിച്ച്, കംപൈലേഷൻ സമയത്ത് wchar_t ന്റെ വലുപ്പവും 2 ബൈറ്റുകൾ ആണെന്ന് നിങ്ങൾക്ക് വ്യക്തമാക്കാൻ കഴിയും, എന്നാൽ കംപൈലറിൽ നിന്ന് സ്റ്റാൻഡേർഡ് ലൈബ്രറി ഉപയോഗിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് മറക്കാം, കാരണം ഇത് glibc ഉപയോഗിക്കുന്നു, ഇത് 4-ബൈറ്റ് wchar_t-നായി സമാഹരിച്ചിരിക്കുന്നു. സ്റ്റാൻഡേർഡ് ക്ലാസുകൾ മികച്ച രീതിയിൽ നടപ്പിലാക്കുക, ഹാഷ് ടേബിളുകൾക്കുള്ള പിന്തുണ, ഞങ്ങൾ സജീവമായി ഉപയോഗിച്ചിരുന്ന കണ്ടെയ്‌നറുകൾക്കുള്ളിൽ ചലിക്കുന്ന സെമാന്റിക്‌സിന്റെ അനുകരണം എന്നിവയായിരുന്നു മറ്റ് കാരണങ്ങൾ. ഒരു കാരണം കൂടി, അവർ അവസാനമായി പറയുന്നത് പോലെ, സ്ട്രിംഗ് പ്രകടനമായിരുന്നു. സ്ട്രിംഗുകൾക്കായി ഞങ്ങൾക്ക് ഞങ്ങളുടെ സ്വന്തം ക്ലാസ് ഉണ്ടായിരുന്നു, കാരണം... ഞങ്ങളുടെ സോഫ്‌റ്റ്‌വെയറിന്റെ പ്രത്യേകതകൾ കാരണം, സ്ട്രിംഗ് ഓപ്പറേഷനുകൾ വളരെ വ്യാപകമായി ഉപയോഗിക്കപ്പെടുന്നു, ഞങ്ങൾക്ക് ഇത് നിർണായകമാണ്.

ഞങ്ങളുടെ സ്ട്രിംഗ് 2000-കളുടെ തുടക്കത്തിൽ പ്രകടിപ്പിച്ച സ്ട്രിംഗ് ഒപ്റ്റിമൈസേഷൻ ആശയങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ആൻഡ്രി അലക്‌സാണ്ട്രെസ്കു. പിന്നീട്, അലക്സാണ്ടറെസ്ക്യൂ ഫേസ്ബുക്കിൽ ജോലി ചെയ്തപ്പോൾ, അദ്ദേഹത്തിന്റെ നിർദ്ദേശപ്രകാരം, സമാനമായ തത്ത്വങ്ങളിൽ പ്രവർത്തിക്കുന്ന ഒരു വരി ഫേസ്ബുക്ക് എഞ്ചിനിൽ ഉപയോഗിച്ചു (ലൈബ്രറി കാണുക. ഭോഷത്വം).

ഞങ്ങളുടെ ലൈൻ രണ്ട് പ്രധാന ഒപ്റ്റിമൈസേഷൻ സാങ്കേതികവിദ്യകൾ ഉപയോഗിച്ചു:

1. ഹ്രസ്വ മൂല്യങ്ങൾക്കായി, സ്ട്രിംഗ് ഒബ്‌ജക്റ്റിൽ തന്നെ ഒരു ആന്തരിക ബഫർ ഉപയോഗിക്കുന്നു (അധിക മെമ്മറി അലോക്കേഷൻ ആവശ്യമില്ല).
2. മറ്റെല്ലാവർക്കും, മെക്കാനിക്സ് ഉപയോഗിക്കുന്നു കോപ്പി ഓൺ റൈറ്റ്. സ്ട്രിംഗ് മൂല്യം ഒരിടത്ത് സംഭരിക്കുന്നു, അസൈൻമെന്റ്/മാറ്റം വരുത്തുമ്പോൾ ഒരു റഫറൻസ് കൗണ്ടർ ഉപയോഗിക്കുന്നു.

പ്ലാറ്റ്ഫോം കംപൈലേഷൻ വേഗത്തിലാക്കാൻ, ഞങ്ങളുടെ STLPort വേരിയന്റിൽ നിന്ന് സ്ട്രീം നടപ്പിലാക്കൽ ഞങ്ങൾ ഒഴിവാക്കി (അത് ഞങ്ങൾ ഉപയോഗിച്ചിട്ടില്ല), ഇത് ഞങ്ങൾക്ക് ഏകദേശം 20% വേഗത്തിലുള്ള സമാഹാരം നൽകി. പിന്നീട് ഞങ്ങൾക്ക് പരിമിതമായ ഉപയോഗങ്ങൾ നൽകേണ്ടി വന്നു ഉത്തേജിപ്പിക്കുക. ബൂസ്റ്റ് സ്ട്രീം വളരെയധികം ഉപയോഗിക്കുന്നു, പ്രത്യേകിച്ച് അതിന്റെ സേവന API-കളിൽ (ഉദാഹരണത്തിന്, ലോഗിംഗിന്), അതിനാൽ സ്ട്രീമിന്റെ ഉപയോഗം നീക്കംചെയ്യുന്നതിന് ഞങ്ങൾക്ക് അത് പരിഷ്‌ക്കരിക്കേണ്ടിവന്നു. ഇത്, ബൂസ്റ്റിന്റെ പുതിയ പതിപ്പുകളിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നത് ഞങ്ങൾക്ക് ബുദ്ധിമുട്ടാക്കി.

മൂന്നാമത്തെ വഴി

C++14 സ്റ്റാൻഡേർഡിലേക്ക് നീങ്ങുമ്പോൾ, ഞങ്ങൾ ഇനിപ്പറയുന്ന ഓപ്ഷനുകൾ പരിഗണിച്ചു:

1. ഞങ്ങൾ പരിഷ്കരിച്ച STLPort C++14 നിലവാരത്തിലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുക. ഓപ്ഷൻ വളരെ ബുദ്ധിമുട്ടാണ്, കാരണം ... STLPort-നുള്ള പിന്തുണ 2010-ൽ നിർത്തലാക്കി, അതിന്റെ എല്ലാ കോഡുകളും ഞങ്ങൾ തന്നെ നിർമ്മിക്കേണ്ടതുണ്ട്.
2. C++14-ന് അനുയോജ്യമായ മറ്റൊരു STL നടപ്പിലാക്കലിലേക്കുള്ള മാറ്റം. വിൻഡോസിനും ലിനക്സിനും വേണ്ടിയുള്ള ഈ നടപ്പാക്കൽ വളരെ അഭികാമ്യമാണ്.
3. ഓരോ OS-നും വേണ്ടി കംപൈൽ ചെയ്യുമ്പോൾ, അനുബന്ധ കമ്പൈലറിൽ നിർമ്മിച്ച ലൈബ്രറി ഉപയോഗിക്കുക.

വളരെയധികം ജോലി കാരണം ആദ്യ ഓപ്ഷൻ പൂർണ്ണമായും നിരസിച്ചു.

ഞങ്ങൾ കുറച്ച് സമയം രണ്ടാമത്തെ ഓപ്ഷനെക്കുറിച്ച് ചിന്തിച്ചു; സ്ഥാനാർത്ഥിയായി കണക്കാക്കുന്നു libc++, എന്നാൽ അക്കാലത്ത് അത് വിൻഡോസിന് കീഴിൽ പ്രവർത്തിച്ചില്ല. Windows-ലേക്ക് libc++ പോർട്ട് ചെയ്യുന്നതിന്, നിങ്ങൾ ഒരുപാട് ജോലികൾ ചെയ്യേണ്ടിവരും - ഉദാഹരണത്തിന്, ഈ മേഖലകളിൽ libc++ ഉപയോഗിച്ചതിനാൽ, ത്രെഡുകൾ, ത്രെഡ് സിൻക്രൊണൈസേഷൻ, ആറ്റോമിസിറ്റി എന്നിവയുമായി ബന്ധപ്പെട്ടതെല്ലാം സ്വയം എഴുതുക. POSIX API.

ഞങ്ങൾ മൂന്നാമത്തെ വഴി തിരഞ്ഞെടുത്തു.

പരിവർത്തനം

അതിനാൽ, ഞങ്ങൾ STLPort-ന്റെ ഉപയോഗം അനുബന്ധ കമ്പൈലറുകളുടെ ലൈബ്രറികൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കേണ്ടതുണ്ട് (Windows-നുള്ള വിഷ്വൽ സ്റ്റുഡിയോ 2015, Linux-ന് gcc 7, macOS-ന് clang 8).

ഭാഗ്യവശാൽ, ഞങ്ങളുടെ കോഡ് പ്രധാനമായും മാർഗ്ഗനിർദ്ദേശങ്ങൾക്കനുസൃതമായി എഴുതിയതാണ്, മാത്രമല്ല എല്ലാത്തരം ബുദ്ധിപരമായ തന്ത്രങ്ങളും ഉപയോഗിച്ചിട്ടില്ല, അതിനാൽ പുതിയ ലൈബ്രറികളിലേക്കുള്ള മൈഗ്രേഷൻ താരതമ്യേന സുഗമമായി നടന്നു, തരങ്ങൾ, ക്ലാസുകൾ, നെയിംസ്പേസുകൾ എന്നിവയുടെ പേരുകൾ മാറ്റി ഉറവിടത്തിൽ ഉൾപ്പെടുത്തിയിട്ടുള്ള സ്ക്രിപ്റ്റുകളുടെ സഹായത്തോടെ. ഫയലുകൾ. മൈഗ്രേഷൻ 10 ഉറവിട ഫയലുകളെ ബാധിച്ചു (000 ൽ). wchar_t-ന് പകരം char14_t; wchar_t ഉപയോഗം ഉപേക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, കാരണം char000_t എല്ലാ OS-കളിലും 16 ബൈറ്റുകൾ എടുക്കുന്നു, Windows-നും Linux-നും ഇടയിലുള്ള കോഡ് അനുയോജ്യത നശിപ്പിക്കില്ല.

ചെറിയ ചില സാഹസങ്ങൾ ഉണ്ടായിരുന്നു. ഉദാഹരണത്തിന്, STLPort-ൽ ഒരു ഇറ്ററേറ്റർ ഒരു ഘടകത്തിലേക്കുള്ള പോയിന്ററിലേക്ക് പരോക്ഷമായി കാസ്‌റ്റ് ചെയ്യാം, ഞങ്ങളുടെ കോഡിൽ ചില സ്ഥലങ്ങളിൽ ഇത് ഉപയോഗിച്ചു. പുതിയ ലൈബ്രറികളിൽ ഇത് ചെയ്യാൻ ഇനി സാധ്യമല്ല, ഈ ഭാഗങ്ങൾ വിശകലനം ചെയ്യുകയും സ്വമേധയാ വീണ്ടും എഴുതുകയും ചെയ്യേണ്ടതുണ്ട്.

അതിനാൽ, കോഡ് മൈഗ്രേഷൻ പൂർത്തിയായി, എല്ലാ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾക്കുമായി കോഡ് സമാഹരിച്ചിരിക്കുന്നു. ഇത് പരീക്ഷകളുടെ സമയമാണ്.

പരിവർത്തനത്തിനു ശേഷമുള്ള പരിശോധനകൾ, കോഡിന്റെ പഴയ പതിപ്പിനെ അപേക്ഷിച്ച് പ്രകടനത്തിൽ കുറവും (ചില സ്ഥലങ്ങളിൽ 20-30% വരെ) മെമ്മറി ഉപഭോഗത്തിൽ (10-15% വരെ) വർദ്ധനവും കാണിച്ചു. ഇത് പ്രത്യേകിച്ചും, സ്റ്റാൻഡേർഡ് സ്ട്രിംഗുകളുടെ ഉപോൽപ്പന്ന പ്രകടനം മൂലമായിരുന്നു. അതിനാൽ, ഞങ്ങൾക്ക് വീണ്ടും ഞങ്ങളുടെ സ്വന്തം, ചെറുതായി പരിഷ്കരിച്ച ലൈൻ ഉപയോഗിക്കേണ്ടിവന്നു.

ഉൾച്ചേർത്ത ലൈബ്രറികളിൽ കണ്ടെയ്‌നറുകൾ നടപ്പിലാക്കുന്നതിന്റെ രസകരമായ ഒരു സവിശേഷതയും വെളിപ്പെടുത്തി: ശൂന്യമായ (ഘടകങ്ങളില്ലാതെ) std::map, std:: ബിൽറ്റ്-ഇൻ ലൈബ്രറികളിൽ നിന്നുള്ള സെറ്റ് മെമ്മറി അലോക്കേറ്റ് ചെയ്യുന്നു. നടപ്പാക്കൽ സവിശേഷതകൾ കാരണം, ചില സ്ഥലങ്ങളിൽ കോഡിൽ ഇത്തരത്തിലുള്ള ധാരാളം ശൂന്യമായ പാത്രങ്ങൾ സൃഷ്ടിക്കപ്പെടുന്നു. ഒരു റൂട്ട് എലമെന്റിനായി സ്റ്റാൻഡേർഡ് മെമ്മറി കണ്ടെയ്നറുകൾ കുറച്ച് അനുവദിച്ചിരിക്കുന്നു, പക്ഷേ ഞങ്ങൾക്ക് ഇത് നിർണായകമായി മാറി - നിരവധി സാഹചര്യങ്ങളിൽ, ഞങ്ങളുടെ പ്രകടനം ഗണ്യമായി കുറയുകയും മെമ്മറി ഉപഭോഗം വർദ്ധിക്കുകയും ചെയ്തു (STLPort നെ അപേക്ഷിച്ച്). അതിനാൽ, ഞങ്ങളുടെ കോഡിൽ, ബിൽറ്റ്-ഇൻ ലൈബ്രറികളിൽ നിന്ന് ഈ രണ്ട് തരം കണ്ടെയ്‌നറുകൾ ഞങ്ങൾ മാറ്റിസ്ഥാപിച്ചു, ഈ കണ്ടെയ്‌നറുകൾക്ക് ഈ സവിശേഷത ഇല്ലാതിരുന്ന ബൂസ്റ്റിൽ നിന്ന് അവ നടപ്പിലാക്കി, ഇത് സ്ലോഡൗൺ, വർദ്ധിച്ച മെമ്മറി ഉപഭോഗം എന്നിവയിലെ പ്രശ്നം പരിഹരിച്ചു.

വലിയ പ്രോജക്റ്റുകളിൽ വലിയ തോതിലുള്ള മാറ്റങ്ങൾക്ക് ശേഷം പലപ്പോഴും സംഭവിക്കുന്നത് പോലെ, സോഴ്സ് കോഡിന്റെ ആദ്യ ആവർത്തനം പ്രശ്നങ്ങളില്ലാതെ പ്രവർത്തിച്ചില്ല, ഇവിടെ, പ്രത്യേകിച്ച്, വിൻഡോസ് നടപ്പാക്കലിൽ ഡീബഗ്ഗിംഗ് ഇറ്ററേറ്ററുകൾക്കുള്ള പിന്തുണ ഉപയോഗപ്രദമായി. ഘട്ടം ഘട്ടമായി ഞങ്ങൾ മുന്നോട്ട് പോയി, 2017 ലെ വസന്തകാലത്തോടെ (പതിപ്പ് 8.3.11 1C: എന്റർപ്രൈസ്) മൈഗ്രേഷൻ പൂർത്തിയായി.

ഫലങ്ങൾ

C++14 സ്റ്റാൻഡേർഡിലേക്കുള്ള മാറ്റം ഞങ്ങൾക്ക് ഏകദേശം 6 മാസമെടുത്തു. മിക്കപ്പോഴും, ഒരു (എന്നാൽ വളരെ ഉയർന്ന യോഗ്യതയുള്ള) ഡവലപ്പർ പ്രോജക്റ്റിൽ പ്രവർത്തിച്ചു, അവസാന ഘട്ടത്തിൽ നിർദ്ദിഷ്ട മേഖലകളുടെ ഉത്തരവാദിത്തമുള്ള ടീമുകളുടെ പ്രതിനിധികൾ - യുഐ, സെർവർ ക്ലസ്റ്റർ, വികസനം, അഡ്മിനിസ്ട്രേഷൻ ഉപകരണങ്ങൾ മുതലായവയിൽ ചേർന്നു.

സ്റ്റാൻഡേർഡിന്റെ ഏറ്റവും പുതിയ പതിപ്പുകളിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നതിനുള്ള ഞങ്ങളുടെ ജോലി ഈ പരിവർത്തനം വളരെ ലളിതമാക്കി. അങ്ങനെ, പതിപ്പ് 1C: എന്റർപ്രൈസ് 8.3.14 (വികസനത്തിൽ, അടുത്ത വർഷം ആദ്യം റിലീസ് ഷെഡ്യൂൾ ചെയ്‌തിരിക്കുന്നു) ഇതിനകം സ്റ്റാൻഡേർഡിലേക്ക് മാറ്റി C++17.

മൈഗ്രേഷനുശേഷം, ഡെവലപ്പർമാർക്ക് കൂടുതൽ ഓപ്ഷനുകൾ ഉണ്ട്. നേരത്തെ ഞങ്ങൾക്ക് STL-ന്റെ പരിഷ്‌ക്കരിച്ച പതിപ്പും ഒരു std നെയിംസ്‌പെയ്‌സും ഉണ്ടായിരുന്നുവെങ്കിൽ, ഇപ്പോൾ ഞങ്ങൾക്ക് std നെയിംസ്‌പേസിലെ ബിൽറ്റ്-ഇൻ കംപൈലർ ലൈബ്രറികളിൽ നിന്ന് സ്റ്റാൻഡേർഡ് ക്ലാസുകൾ ഉണ്ട്, stdx നെയിംസ്‌പെയ്‌സിൽ - ഞങ്ങളുടെ ലൈനുകളും കണ്ടെയ്‌നറുകളും ഞങ്ങളുടെ ടാസ്‌ക്കുകൾക്കായി ഒപ്റ്റിമൈസ് ചെയ്‌തിരിക്കുന്നു, ബൂസ്റ്റിൽ - ബൂസ്റ്റിന്റെ ഏറ്റവും പുതിയ പതിപ്പ്. ഡെവലപ്പർ തന്റെ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഏറ്റവും അനുയോജ്യമായ ക്ലാസുകൾ ഉപയോഗിക്കുന്നു.

മൂവ് കൺസ്‌ട്രക്‌ടറുകളുടെ "നേറ്റീവ്" നടപ്പിലാക്കലും വികസനത്തിന് സഹായിക്കുന്നു (കൺസ്ട്രക്റ്റർമാരെ നീക്കുക) നിരവധി ക്ലാസുകൾക്ക്. ഒരു ക്ലാസിന് ഒരു മൂവ് കൺസ്ട്രക്റ്റർ ഉണ്ടെങ്കിൽ, ഈ ക്ലാസ് ഒരു കണ്ടെയ്‌നറിൽ സ്ഥാപിക്കുകയാണെങ്കിൽ, കണ്ടെയ്‌നറിനുള്ളിലെ മൂലകങ്ങളുടെ പകർപ്പ് STL ഒപ്റ്റിമൈസ് ചെയ്യുന്നു (ഉദാഹരണത്തിന്, കണ്ടെയ്‌നർ വികസിക്കുമ്പോൾ ശേഷി മാറ്റുകയും മെമ്മറി വീണ്ടും അനുവദിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്).

തൈലത്തിനുള്ളിൽ പറക്കുക

ഒരുപക്ഷേ കുടിയേറ്റത്തിന്റെ ഏറ്റവും അസുഖകരമായ (പക്ഷേ നിർണായകമല്ല) അനന്തരഫലം വോളിയത്തിൽ വർദ്ധനവ് ഞങ്ങൾ അഭിമുഖീകരിക്കുന്നു എന്നതാണ്. obj ഫയലുകൾ, കൂടാതെ എല്ലാ ഇന്റർമീഡിയറ്റ് ഫയലുകളുമുള്ള ബിൽഡിന്റെ പൂർണ്ണ ഫലം 60-70 GB വരെ എടുക്കാൻ തുടങ്ങി. ഈ സ്വഭാവം ആധുനിക സ്റ്റാൻഡേർഡ് ലൈബ്രറികളുടെ പ്രത്യേകതകൾ മൂലമാണ്, ജനറേറ്റഡ് സർവീസ് ഫയലുകളുടെ വലിപ്പം കുറച്ചുകൂടി വിമർശനാത്മകമായിത്തീർന്നു. ഇത് കംപൈൽ ചെയ്ത ആപ്ലിക്കേഷന്റെ പ്രവർത്തനത്തെ ബാധിക്കില്ല, പക്ഷേ ഇത് വികസനത്തിൽ നിരവധി അസൌകര്യങ്ങൾ ഉണ്ടാക്കുന്നു, പ്രത്യേകിച്ചും, ഇത് സമാഹരിക്കുന്ന സമയം വർദ്ധിപ്പിക്കുന്നു. ബിൽഡ് സെർവറുകളിലും ഡവലപ്പർ മെഷീനുകളിലും സൗജന്യ ഡിസ്ക് സ്ഥലത്തിനുള്ള ആവശ്യകതകളും വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണ്. ഞങ്ങളുടെ ഡെവലപ്പർമാർ പ്ലാറ്റ്‌ഫോമിന്റെ നിരവധി പതിപ്പുകളിൽ സമാന്തരമായി പ്രവർത്തിക്കുന്നു, നൂറുകണക്കിന് ജിഗാബൈറ്റ് ഇന്റർമീഡിയറ്റ് ഫയലുകൾ ചിലപ്പോൾ അവരുടെ ജോലിയിൽ ബുദ്ധിമുട്ടുകൾ സൃഷ്ടിക്കുന്നു. പ്രശ്നം അസുഖകരമാണ്, പക്ഷേ വിമർശനാത്മകമല്ല; ഞങ്ങൾ അതിന്റെ പരിഹാരം ഇപ്പോൾ മാറ്റിവച്ചു. അത് പരിഹരിക്കുന്നതിനുള്ള ഓപ്ഷനുകളിലൊന്നായി ഞങ്ങൾ സാങ്കേതികവിദ്യയെ പരിഗണിക്കുന്നു ഐക്യം കെട്ടിപ്പടുക്കുക (പ്രത്യേകിച്ച്, Chrome ബ്രൗസർ വികസിപ്പിക്കുമ്പോൾ Google ഇത് ഉപയോഗിക്കുന്നു).

അവലംബം: www.habr.com