როგორ გადავთარგმნეთ C++ კოდის 10 მილიონი ხაზი C++14 სტანდარტზე (და შემდეგ C++17)

რამდენიმე ხნის წინ (2016 წლის შემოდგომაზე), 1C: Enterprise ტექნოლოგიური პლატფორმის შემდეგი ვერსიის შემუშავებისას, დეველოპერების გუნდში გაჩნდა კითხვა ახალი სტანდარტის მხარდაჭერის შესახებ. C ++ 14 ჩვენს კოდში. ახალ სტანდარტზე გადასვლა, როგორც ვივარაუდეთ, მოგვცემს საშუალებას დავწეროთ ბევრი რამ უფრო ელეგანტურად, მარტივად და საიმედოდ და გაამარტივებს კოდის მხარდაჭერასა და შენარჩუნებას. და, როგორც ჩანს, თარგმანში არაფერია უჩვეულო, რომ არა კოდის ბაზის მასშტაბი და ჩვენი კოდის სპეციფიკური მახასიათებლები.

მათთვის, ვინც არ იცის, 1C:Enterprise არის გარემო მრავალპლატფორმული ბიზნეს აპლიკაციების სწრაფი განვითარებისთვის და მათი შესრულებისთვის სხვადასხვა OS-ებსა და DBMS-ებზე. ზოგადად, პროდუქტი შეიცავს:

• განაცხადის სერვერის კლასტერი, მუშაობს Windows-ზე და Linux-ზე
• დამკვეთი, სერვერთან მუშაობა http(s) ან საკუთარი ორობითი პროტოკოლით, მუშაობს Windows, Linux, macOS-ზე
• ვებ კლიენტი, მუშაობს Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari ბრაუზერებში (დაწერილი JavaScript-ში)
• განვითარების გარემო (კონფიგურატორი), მუშაობს Windows, Linux, macOS-ზე
• ადმინისტრაციის ინსტრუმენტები აპლიკაციის სერვერები, მუშაობს Windows-ზე, Linux-ზე, macOS-ზე
• მობილური კლიენტი, სერვერთან დაკავშირება http(s) საშუალებით, მუშაობს მობილურ მოწყობილობებზე, რომლებიც მუშაობენ Android, iOS, Windows
• მობილური პლატფორმა — ჩარჩო ოფლაინ მობილური აპლიკაციების შესაქმნელად სინქრონიზაციის შესაძლებლობით, გაშვებული Android-ზე, iOS-ზე, Windows-ზე
• განვითარების გარემო 1C: საწარმოს განვითარების ინსტრუმენტებიჯავაზე დაწერილი
• სერვერი ურთიერთქმედების სისტემები

ჩვენ ვცდილობთ დავწეროთ ერთი და იგივე კოდი სხვადასხვა ოპერაციული სისტემისთვის - სერვერის კოდის ბაზა 99% საერთოა, კლიენტის კოდის ბაზა დაახლოებით 95%. 1C: Enterprise ტექნოლოგიური პლატფორმა ძირითადად დაწერილია C++-ში და კოდის სავარაუდო მახასიათებლები მოცემულია ქვემოთ:

• C++ კოდის 10 მილიონი ხაზი,
• 14 ათასი ფაილი,
• 60 ათასი კლასი,
• ნახევარი მილიონი მეთოდი.

და ეს ყველაფერი უნდა გადათარგმნილიყო C++14-ზე. დღეს ჩვენ გეტყვით, როგორ გავაკეთეთ ეს და რა შეგვხვდა ამ პროცესში.

პასუხისმგებლობის უარყოფა

ყველაფერი დაწერილი ქვემოთ ნელი/სწრაფი მუშაობის შესახებ, (არა) დიდი მეხსიერების მოხმარება სტანდარტული კლასების განხორციელებით სხვადასხვა ბიბლიოთეკაში ნიშნავს ერთ რამეს: ეს მართალია ჩვენთვის. სავსებით შესაძლებელია, რომ სტანდარტული განხორციელებები საუკეთესოდ შეეფერება თქვენს ამოცანებს. ჩვენ დავიწყეთ ჩვენი საკუთარი ამოცანებიდან: ავიღეთ მონაცემები, რომლებიც დამახასიათებელი იყო ჩვენი კლიენტებისთვის, ჩავატარეთ მათზე ტიპიური სცენარები, დავაკვირდით შესრულებას, მოხმარებული მეხსიერების რაოდენობას და ა.შ. . და მოქმედებდნენ იმის მიხედვით.

რაც გვქონდა

თავდაპირველად ჩვენ დავწერეთ კოდი 1C:Enterprise 8 პლატფორმისთვის Microsoft Visual Studio-ში. პროექტი დაიწყო 2000-იანი წლების დასაწყისში და გვქონდა მხოლოდ Windows-ის ვერსია. ბუნებრივია, მას შემდეგ კოდი აქტიურად განვითარდა, ბევრი მექანიზმი მთლიანად გადაიწერა. მაგრამ კოდი დაიწერა 1998 წლის სტანდარტის მიხედვით და, მაგალითად, ჩვენი მართი კუთხის ფრჩხილები იყო გამოყოფილი სივრცეებით ისე, რომ კომპილაცია წარმატებული ყოფილიყო, ასე:

vector<vector<int> > IntV;

2006 წელს, პლატფორმის 8.1 ვერსიის გამოშვებით, ჩვენ დავიწყეთ Linux-ის მხარდაჭერა და გადავედით მესამე მხარის სტანდარტულ ბიბლიოთეკაზე. STLPort. გადასვლის ერთ-ერთი მიზეზი ფართო ხაზებით მუშაობა იყო. ჩვენს კოდში ჩვენ ვიყენებთ std::wstring, რომელიც დაფუძნებულია wchar_t ტიპზე, მთელი. მისი ზომა ვინდოუსში არის 2 ბაიტი, ხოლო Linux-ში ნაგულისხმევი არის 4 ბაიტი. ამან გამოიწვია ჩვენი ორობითი პროტოკოლების შეუთავსებლობა კლიენტსა და სერვერს შორის, ასევე სხვადასხვა მუდმივ მონაცემებს შორის. gcc პარამეტრების გამოყენებით შეგიძლიათ მიუთითოთ, რომ wchar_t-ის ზომა კომპილაციის დროს ასევე არის 2 ბაიტი, მაგრამ შემდეგ შეგიძლიათ დაივიწყოთ კომპილატორიდან სტანდარტული ბიბლიოთეკის გამოყენება, რადგან ის იყენებს glibc-ს, რომელიც თავის მხრივ შედგენილია 4-ბაიტიანი wchar_t. სხვა მიზეზები იყო სტანდარტული კლასების უკეთესი განხორციელება, ჰეშის ცხრილების მხარდაჭერა და კონტეინერებში გადაადგილების სემანტიკის ემულაციაც კი, რასაც ჩვენ აქტიურად ვიყენებდით. და კიდევ ერთი მიზეზი, როგორც ამბობენ ბოლოს და ბოლოს, იყო სიმებიანი შესრულება. ჩვენ გვქონდა სიმებიანი კლასი, რადგან... ჩვენი პროგრამული უზრუნველყოფის სპეციფიკიდან გამომდინარე, სიმებიანი ოპერაციები ძალიან ფართოდ გამოიყენება და ჩვენთვის ეს კრიტიკულია.

ჩვენი სტრიქონი ეფუძნება სტრიქონების ოპტიმიზაციის იდეებს, რომლებიც გამოთქმული იყო ჯერ კიდევ 2000-იანი წლების დასაწყისში ანდრეი ალექსანდრესკუ. მოგვიანებით, როდესაც ალექსანდრესკუ Facebook-ში მუშაობდა, მისი წინადადებით, Facebook-ის ძრავში გამოიყენეს ხაზი, რომელიც მუშაობდა მსგავს პრინციპებზე (იხ. ბიბლიოთეკა folly).

ჩვენი ხაზი იყენებდა ორ ძირითად ოპტიმიზაციის ტექნოლოგიას:

1. მოკლე მნიშვნელობებისთვის გამოიყენება შიდა ბუფერი სტრიქონის ობიექტში (არ საჭიროებს დამატებით მეხსიერების განაწილებას).
2. ყველა დანარჩენისთვის გამოიყენება მექანიკა კოპირება ჩაწერაზე. სტრიქონის მნიშვნელობა ინახება ერთ ადგილას და მითითების მრიცხველი გამოიყენება მინიჭების/მოდიფიკაციის დროს.

პლატფორმის შედგენის დასაჩქარებლად, ჩვენ გამოვრიცხეთ ნაკადის განხორციელება ჩვენი STLPort ვარიანტიდან (რომელიც ჩვენ არ გამოგვიყენებია), ამან მოგვცა დაახლოებით 20% უფრო სწრაფი შედგენა. შემდგომში მოგვიწია შეზღუდული გამოყენება ისევე როგორც. Boost აქტიურად იყენებს სტრიმინგს, განსაკუთრებით მისი სერვისის API-ებში (მაგალითად, ლოგინგისთვის), ამიტომ ჩვენ მოგვიწია მისი შეცვლა, რათა ამოგვეშალა ნაკადის გამოყენება. ამან, თავის მხრივ, გაგვირთულა Boost-ის ახალ ვერსიებზე გადასვლა.

მესამე გზა

C++14 სტანდარტზე გადასვლისას განვიხილეთ შემდეგი ვარიანტები:

1. განაახლეთ STLPort ჩვენ მიერ შეცვლილი C++14 სტანდარტზე. ვარიანტი ძალიან რთულია, რადგან... STLPort-ის მხარდაჭერა 2010 წელს შეწყდა და ჩვენ თვითონ მოგვიწევდა მისი მთელი კოდის შექმნა.
2. გადასვლა სხვა STL განხორციელებაზე, რომელიც თავსებადია C++14-თან. ძალიან სასურველია, რომ ეს განხორციელება იყოს Windows-ისთვის და Linux-ისთვის.
3. თითოეული OS-ისთვის შედგენისას გამოიყენეთ ბიბლიოთეკა, რომელიც ჩაშენებულია შესაბამის შემდგენელში.

პირველი ვარიანტი პირდაპირ უარყოფილ იქნა ზედმეტი მუშაობის გამო.

მეორე ვარიანტზე ცოტა ხანი ვიფიქრეთ; კანდიდატად განიხილება libc++, მაგრამ იმ დროს ის Windows-ის ქვეშ არ მუშაობდა. libc++ Windows-ზე გადასატანად, ბევრი სამუშაო მოგიწევთ - მაგალითად, დაწერეთ ყველაფერი, რაც დაკავშირებულია ძაფებთან, ძაფების სინქრონიზაციასთან და ატომურობასთან, რადგან libc++ გამოიყენება ამ ადგილებში. POSIX API.

და ჩვენ ავირჩიეთ მესამე გზა.

Გარდამავალი

ასე რომ, ჩვენ უნდა შეგვეცვალა STLPort-ის გამოყენება შესაბამისი შემდგენელების ბიბლიოთეკებით (Visual Studio 2015 Windows-ისთვის, gcc 7 Linux-ისთვის, clang 8 macOS-ისთვის).

საბედნიეროდ, ჩვენი კოდი დაიწერა ძირითადად გაიდლაინების მიხედვით და არ იყენებდა ყველა სახის ჭკვიან ხრიკს, ამიტომ ახალ ბიბლიოთეკებში მიგრაცია შედარებით შეუფერხებლად მიმდინარეობდა, სკრიპტების დახმარებით, რომლებმაც შეცვალეს ტიპების, კლასების, სახელების სივრცის სახელები და ჩართულია წყაროში. ფაილები. მიგრაცია შეეხო 10 წყაროს ფაილს (000-დან). wchar_t შეიცვალა char14_t-ით; ჩვენ გადავწყვიტეთ უარი ვთქვათ wchar_t-ის გამოყენებაზე, რადგან char000_t იღებს 16 ბაიტს ყველა OS-ზე და არ აფუჭებს კოდის თავსებადობას Windows-სა და Linux-ს შორის.

იყო რამდენიმე პატარა თავგადასავლები. მაგალითად, STLPort-ში იტერატორი შეიძლება იყოს მინიშნებული ელემენტის მაჩვენებელზე და ჩვენს კოდში ზოგიერთ ადგილას ეს იყო გამოყენებული. ახალ ბიბლიოთეკებში ამის გაკეთება უკვე შეუძლებელი იყო და ეს პასაჟები ხელით უნდა გაანალიზებულიყო და გადაეწერა.

ასე რომ, კოდის მიგრაცია დასრულებულია, კოდი შედგენილია ყველა ოპერაციული სისტემისთვის. ტესტების დროა.

გადასვლის შემდეგ ტესტებმა აჩვენა შესრულების ვარდნა (ზოგიერთ ადგილას 20-30%-მდე) და მეხსიერების მოხმარების ზრდა (10-15%-მდე) კოდის ძველ ვერსიასთან შედარებით. ეს იყო, კერძოდ, სტანდარტული სიმების არაოპტიმალური შესრულების გამო. ამიტომ, კვლავ მოგვიწია საკუთარი, ოდნავ შეცვლილი ხაზის გამოყენება.

ასევე გამოვლინდა ჩაშენებულ ბიბლიოთეკებში კონტეინერების განხორციელების საინტერესო თვისება: ცარიელი (ელემენტების გარეშე) std::map და std::set ჩაშენებული ბიბლიოთეკებიდან გამოყოფს მეხსიერებას. და განხორციელების მახასიათებლების გამო, კოდის ზოგიერთ ადგილას იქმნება ამ ტიპის საკმაოდ ბევრი ცარიელი კონტეინერი. სტანდარტული მეხსიერების კონტეინერები გამოყოფილია ცოტათი, ერთი ძირეული ელემენტისთვის, მაგრამ ჩვენთვის ეს კრიტიკული აღმოჩნდა - რიგ სცენარებში, ჩვენი შესრულება მნიშვნელოვნად დაეცა და მეხსიერების მოხმარება გაიზარდა (STLPort-თან შედარებით). ამიტომ, ჩვენს კოდში ჩვენ შევცვალეთ ეს ორი ტიპის კონტეინერი ჩაშენებული ბიბლიოთეკებიდან მათი იმპლემენტაციით Boost-დან, სადაც ამ კონტეინერებს არ გააჩნდათ ეს ფუნქცია და ამან მოაგვარა პრობლემა შენელებისა და მეხსიერების მოხმარების გაზრდით.

როგორც ხშირად ხდება მსხვილ პროექტებში ფართომასშტაბიანი ცვლილებების შემდეგ, წყაროს კოდის პირველმა გამეორებამ უპრობლემოდ არ იმუშავა და აქ, კერძოდ, Windows-ის დანერგვაში იტერატორების გამართვის მხარდაჭერა გამოდგება. ნაბიჯ-ნაბიჯ წინ წავედით და 2017 წლის გაზაფხულისთვის (ვერსია 8.3.11 1C:Enterprise) მიგრაცია დასრულდა.

შედეგები

C++14 სტანდარტზე გადასვლას დაახლოებით 6 თვე დაგვჭირდა. უმეტეს შემთხვევაში, პროექტზე მუშაობდა ერთი (მაგრამ ძალიან მაღალკვალიფიციური) დეველოპერი, ხოლო საბოლოო ეტაპზე შეუერთდნენ კონკრეტულ სფეროებზე პასუხისმგებელი გუნდების წარმომადგენლები - UI, სერვერის კლასტერი, განვითარებისა და ადმინისტრირების ინსტრუმენტები და ა.შ.

გადასვლამ მნიშვნელოვნად გაამარტივა ჩვენი მუშაობა სტანდარტის უახლეს ვერსიებზე გადატანაზე. ამრიგად, ვერსია 1C:Enterprise 8.3.14 (დამუშავების პროცესშია, გამოშვება დაგეგმილია მომავალი წლის დასაწყისში) უკვე გადავიდა სტანდარტზე C++17.

მიგრაციის შემდეგ, დეველოპერებს მეტი არჩევანი აქვთ. თუ ადრე გვქონდა STL-ის ჩვენი შეცვლილი ვერსია და ერთი std სახელთა სივრცე, ახლა გვაქვს სტანდარტული კლასები ჩაშენებული შემდგენელი ბიბლიოთეკებიდან std სახელთა სივრცეში, stdx სახელთა სივრცეში - ჩვენი ხაზები და კონტეინერები ოპტიმიზირებულია ჩვენი ამოცანებისთვის, boost-ში - გაძლიერების უახლესი ვერსია. და დეველოპერი იყენებს იმ კლასებს, რომლებიც ოპტიმალურად არის შესაფერისი მისი პრობლემების გადასაჭრელად.

გადაადგილების კონსტრუქტორების „მშობლიური“ განხორციელება ასევე ეხმარება განვითარებას (კონსტრუქტორების გადაადგილება) რიგი კლასებისთვის. თუ კლასს აქვს გადაადგილების კონსტრუქტორი და ეს კლასი მოთავსებულია კონტეინერში, მაშინ STL ოპტიმიზაციას უკეთებს კონტეინერის შიგნით ელემენტების კოპირებას (მაგალითად, როდესაც კონტეინერი გაფართოვებულია და საჭიროა ტევადობის შეცვლა და მეხსიერების გადანაწილება).

ფრენა მალამოში

მიგრაციის ყველაზე უსიამოვნო (მაგრამ არა კრიტიკული) შედეგი არის ის, რომ ჩვენ ვხვდებით მოცულობის ზრდას. obj ფაილებიდა ყველა შუალედური ფაილით აშენების სრულმა შედეგმა დაიწყო 60-70 GB-ის დაკავება. ეს ქცევა განპირობებულია თანამედროვე სტანდარტების ბიბლიოთეკების თავისებურებებით, რომლებიც ნაკლებად კრიტიკული გახდა გენერირებული სერვის ფაილების ზომის მიმართ. ეს არ იმოქმედებს შედგენილი აპლიკაციის მუშაობაზე, მაგრამ იწვევს უამრავ უხერხულობას განვითარებაში, კერძოდ, ზრდის შედგენის დროს. ასევე იზრდება მოთხოვნები დისკზე თავისუფალი ადგილის შესახებ build სერვერებზე და დეველოპერ მანქანებზე. ჩვენი დეველოპერები პარალელურად მუშაობენ პლატფორმის რამდენიმე ვერსიაზე და ასობით გიგაბაიტი შუალედური ფაილი ზოგჯერ ქმნის სირთულეებს მათ მუშაობაში. პრობლემა არასასიამოვნოა, მაგრამ არა კრიტიკული, მისი გადაწყვეტა ჯერ გადავდეთ. ჩვენ განვიხილავთ ტექნოლოგიას, როგორც მისი გადაჭრის ერთ-ერთ ვარიანტს ერთიანობის აშენება (კერძოდ, Google იყენებს მას Chrome ბრაუზერის შემუშავებისას).

წყარო: www.habr.com