Sababaraha waktu ka tukang (dina usum gugur 2016), nalika ngembangkeun versi salajengna tina 1C: platform téhnologi Enterprise, patarosan timbul dina tim ngembangkeun ngeunaan ngarojong standar anyar. dina kode urang. Transisi kana standar anyar, sakumaha urang anggap, bakal ngidinan urang nulis loba hal leuwih elegantly, basajan tur reliably, sarta bakal simplify rojongan tur pamaliharaan kode. Sareng sigana teu aya anu luar biasa dina tarjamahan, upami henteu pikeun skala dasar kode sareng fitur khusus kode urang.
Pikeun anu henteu terang, 1C: Enterprise mangrupikeun lingkungan pikeun ngembangkeun gancang aplikasi bisnis cross-platform sareng runtime pikeun palaksanaanna dina OS sareng DBMS anu béda. Sacara umum, produk ngandung:
- , dijalankeun dina Windows sareng Linux
- , gawé bareng server via http(s) atawa protokol binér sorangan, jalan dina Windows, Linux Ubuntu, macOS
- , jalan dina Chrome, Internet Explorer, Microsoft Edge, Firefox, browser Safari (ditulis dina JavaScript)
- Lingkungan Pangwangunan (), jalan dina Windows, Linux, macOS
- server aplikasi, dijalankeun dina Windows, Linux, macOS
- , nyambung ka server via http (s), jalan dina alat nu bagerak ngajalankeun Android, ios, Windows
- - kerangka pikeun nyieun aplikasi mobile offline kalawan kamampuhan pikeun nyingkronkeun, ngajalankeun on Android, ios, Windows
- Lingkungan pangwangunan , ditulis dina basa Jawa
- server
Kami nyobian nyerat kode anu sami pikeun sistem operasi anu béda sabisa-bisa - dasar kode server 99% umum, dasar kode klien sakitar 95%. The 1C: Platform téhnologi Enterprise utamana ditulis dina C++ jeung ciri kode perkiraan dibere handap:
- 10 juta baris kode C++,
- 14 rébu file,
- 60 rébu kelas,
- satengah juta métode.
Sareng sadaya barang ieu kedah ditarjamahkeun kana C ++ 14. Dinten ieu kami bakal nyarioskeun ka anjeun kumaha urang ngalakukeun ieu sareng naon anu urang tepang dina prosésna.
Bantahan
Sagalana ditulis di handap ngeunaan slow / karya gancang, (teu) konsumsi memori badag ku palaksanaan kelas baku di sagala rupa perpustakaan hartina hiji hal: ieu bener keur AS. Ieu rada mungkin yén palaksanaan standar bakal paling cocog pikeun tugas anjeun. Urang mimitian ti tugas urang sorangan: urang nyandak data anu has pikeun klien kami, ngajalankeun skenario has dina aranjeunna, nempo kinerja, jumlah memori dihakan, jsb, sarta dianalisis naha urang jeung klien kami éta wareg jeung hasil sapertos atanapi henteu. . Jeung maranéhna acted gumantung.
Naon urang tadi
Mimitina, urang nyerat kodeu pikeun platform 1C: Enterprise 8 di Microsoft Visual Studio. Proyék dimimitian dina awal 2000-an sareng urang ngagaduhan versi Windows wungkul. Alami, saprak éta kode geus aktip dimekarkeun, loba mékanisme tos rengse ditulis ulang. Tapi kodeu ditulis dumasar kana standar 1998, sareng, contona, kurung sudut katuhu urang dipisahkeun ku rohangan supados kompilasi bakal suksés, sapertos kieu:
vector<vector<int> > IntV;Taun 2006, kalayan dileupaskeun versi platform 8.1, urang mimiti ngadukung Linux sareng ngalih ka perpustakaan standar pihak katilu. . Salah sahiji alesan pikeun transisi éta pikeun digawé kalayan garis lega. Dina kode kami, kami nganggo std :: wstring, anu dumasar kana jinis wchar_t, sapanjang. Ukuranna dina Windows nyaéta 2 bait, sareng dina Linux standarna nyaéta 4 bait. Ieu ngakibatkeun incompatibility tina protokol binér urang antara klien tur server, kitu ogé rupa data pengkuh. Nganggo pilihan gcc, anjeun tiasa netepkeun yén ukuran wchar_t salami kompilasi ogé 2 bait, tapi teras anjeun tiasa hilap nganggo perpustakaan standar tina kompiler, sabab ngagunakeun glibc, anu dina gilirannana disusun pikeun 4-bait wchar_t. Alesan sejenna nya éta palaksanaan hadé tina kelas baku, rojongan pikeun tabel Hash, komo emulation tina semantik pindah jero peti, nu urang aktip dipake. Sareng hiji deui alesan, sakumaha anu aranjeunna nyarioskeun terakhir tapi henteu sakedik, nyaéta pagelaran senar. Kami ngagaduhan kelas sorangan pikeun senar, sabab ... Kusabab spésifik parangkat lunak kami, operasi senar dianggo sacara lega sareng pikeun kami ieu kritis.
string kami dumasar kana gagasan optimasi string dinyatakeun deui dina awal 2000s . Engké, nalika Alexandrescu digawé di Facebook, dina saran-Na, garis dipaké dina mesin Facebook nu digawé dina prinsip sarupa (tingali perpustakaan. ).
Jalur kami nganggo dua téknologi optimasi utama:
- Pikeun nilai pondok dipaké hiji panyangga internal dina obyék string sorangan (teu merlukeun alokasi memori tambahan).
- Pikeun sakabéh séjén, mékanika dipaké . Nilai string disimpen dina hiji tempat, sarta counter rujukan dipaké salila ngerjakeun / modifikasi.
Pikeun nyepetkeun kompilasi platform, kami ngaluarkeun palaksanaan stream tina varian STLPort kami (anu kami henteu nganggo), ieu masihan kami kompilasi 20% langkung gancang. Salajengna, urang kedah nganggo kawates . Boost ngagunakeun aliran anu beurat, khususna dina API jasa na (contona, pikeun logging), janten kami kedah ngarobih pikeun ngahapus panggunaan aliran. Ieu, kahareupna ngajadikeun hésé pikeun urang migrasi ka versi anyar tina Boost.
cara katilu
Nalika ngalih ka standar C ++ 14, kami nganggap pilihan ieu:
- Ningkatkeun STLPort kami dirobah kana standar C ++ 14. Pilihanna sesah pisan, sabab ... rojongan pikeun STLPort ieu dilanjutkeun dina 2010, sarta kami kudu ngawangun sagala kode na sorangan.
- Transisi ka palaksanaan STL sejen cocog sareng C ++ 14. Éta pisan pikaresepeun yén palaksanaan ieu kanggo Windows sareng Linux.
- Nalika kompilasi pikeun tiap OS, nganggo perpustakaan anu diwangun kana kompiler anu saluyu.
Pilihan kahiji ditolak langsung alatan loba teuing gawé.
Urang mikir ngeunaan pilihan kadua pikeun sawatara waktu; dianggap calon , tapi dina waktos éta henteu tiasa dianggo dina Windows. Pikeun port libc ++ ka Windows, anjeun kedah seueur padamelan - contona, nyerat sadayana anu aya hubunganana sareng benang, sinkronisasi benang sareng atomicity, sabab libc ++ dianggo di daérah ieu. .
Sarta kami milih cara katilu.
Transisi
Janten, urang kedah ngagentos panggunaan STLPort sareng perpustakaan kompiler anu saluyu (Visual Studio 2015 pikeun Windows, gcc 7 pikeun Linux, clang 8 pikeun macOS).
Untungna, kode urang ditulis utamana nurutkeun tungtunan jeung teu ngagunakeun sagala sorts trik pinter, jadi migrasi ka perpustakaan anyar proceeded rélatif lancar, kalayan bantuan skrip nu ngaganti ngaran tipe, kelas, namespaces sarta kaasup dina sumber. file. Migrasi mangaruhan 10 file sumber (tina 000). wchar_t diganti ku char14_t; urang mutuskeun pikeun abandon pamakéan wchar_t, sabab char000_t nyandak 16 bait dina sadaya OS sareng henteu ngarusak kasaluyuan kode antara Windows sareng Linux.
Aya sababaraha petualangan leutik. Contona, dina STLPort hiji iterator bisa implicitly tuang ka pointer ka unsur, sarta di sababaraha tempat di kode urang ieu dipaké. Dina perpustakaan anyar teu mungkin deui ngalakukeun ieu, sarta passages ieu kudu dianalisis tur ditulis deui sacara manual.
Janten, migrasi kode parantos réngsé, kodeu disusun pikeun sadaya sistem operasi. Waktosna pikeun tés.
Tés sanggeus transisi némbongkeun hiji serelek dina kinerja (di sababaraha tempat nepi ka 20-30%) jeung kanaékan konsumsi memori (nepi ka 10-15%) dibandingkeun jeung versi heubeul kode. Ieu, hususna, alatan kinerja suboptimal tina string baku. Ku alatan éta, urang deui kedah nganggo garis sorangan, rada dirobah.
Hiji fitur metot palaksanaan peti di perpustakaan embedded ieu ogé wangsit: kosong (tanpa elemen) std :: peta jeung std :: diatur ti diwangun-di perpustakaan allocate memori. Sareng kusabab fitur palaksanaan, di sababaraha tempat dina kodeu seueur wadah kosong tina jinis ieu didamel. Wadah mémori standar dialokasikeun sakedik, pikeun hiji unsur akar, tapi pikeun urang ieu janten kritis - dina sababaraha skenario, kinerja urang turun sacara signifikan sareng konsumsi mémori ningkat (dibandingkeun sareng STLPort). Ku alatan éta, dina kode urang ngaganti dua jenis wadahna ieu ti perpustakaan diwangun-di kalawan palaksanaan maranéhanana ti naekeun, dimana peti ieu teu boga fitur ieu, sarta ieu direngsekeun masalah slowdown jeung ngaronjat konsumsi memori.
Sapertos sering kajadian saatos parobihan skala ageung dina proyék-proyék ageung, pangulangan mimiti kode sumber henteu tiasa dianggo tanpa masalah, sareng di dieu, khususna, dukungan pikeun debugging iterators dina palaksanaan Windows tiasa dianggo. Léngkah-léngkah kami maju, sareng ku cinyusu 2017 (versi 8.3.11 1C: Perusahaan) migrasi parantos réngsé.
hasil
Transisi kana standar C ++ 14 nyandak urang ngeunaan 6 bulan. Kalolobaan waktu, hiji (tapi kacida mumpuni) pamekar dikeureuyeuh proyék, sarta dina tahap ahir wawakil tim jawab wewengkon husus ngagabung - UI, klaster server, ngembangkeun sarta parabot administrasi, jsb.
Transisi pisan nyederhanakeun padamelan urang dina migrasi ka vérsi standar anu pangahirna. Ku kituna, versi 1C: Enterprise 8.3.14 (dina ngembangkeun, release dijadwalkeun pikeun mimiti taun hareup) geus dialihkeun ka standar. .
Saatos migrasi, pamekar gaduh seueur pilihan. Upami sateuacana urang ngagaduhan versi STL anu dirobih sareng hiji rohangan ngaran std, ayeuna urang ngagaduhan kelas standar tina perpustakaan kompiler anu diwangun dina ruang ngaran std, dina ruang ngaran stdx - garis sareng wadah kami dioptimalkeun pikeun tugas urang, dina dorongan - éta versi panganyarna tina dorongan. Sareng pamekar ngagunakeun kelas-kelas anu paling cocog pikeun ngabéréskeun masalahna.
Palaksanaan "asli" tina konstruktor gerak ogé ngabantosan dina pangwangunan () pikeun sababaraha kelas. Lamun kelas ngabogaan constructor move sarta kelas ieu disimpen dina wadahna, mangka STL ngaoptimalkeun nyalin unsur jero wadahna (Contona, nalika wadahna dilegakeun sarta perlu ngarobah kapasitas na reallocate memori).
Hiji sendok tar
Panginten akibat anu paling pikaresepeun (tapi henteu kritis) tina migrasi nyaéta yén urang disanghareupan kanaékan volume. , sareng hasil lengkep tina ngawangun sareng sadaya file panengah mimiti nyandak 60-70 GB. Paripolah ieu disababkeun ku peculiarities perpustakaan standar modern, anu geus jadi kirang kritis kana ukuran file jasa dihasilkeun. Ieu henteu mangaruhan operasi aplikasi anu disusun, tapi nyababkeun sababaraha kasulitan dina pangwangunan, khususna, éta ningkatkeun waktos kompilasi. Sarat pikeun rohangan disk bébas dina ngawangun server sareng dina mesin pamekar ogé ningkat. Pamekar urang dianggo dina sababaraha vérsi platform dina paralel, sarta ratusan gigabytes file panengah kadang nyieun kasusah dina karya maranéhanana. Masalahna henteu pikaresepeun, tapi henteu kritis; kami parantos ditunda solusina pikeun ayeuna. Kami nganggap téknologi salaku salah sahiji pilihan pikeun ngarengsekeunana (khususna, Google nganggo éta nalika ngembangkeun browser Chrome).
sumber: www.habr.com