Demek berê (di payîza sala 2016-an de), di dema pêşkeftina guhertoya din a platforma teknolojiya 1C: Enterprise de, pirs di nav tîmê pêşkeftinê de di derbarê piştgirîkirina standarda nû de derket. di koda me de. Veguheztina standardek nû, wekî ku me texmîn kir, dê bihêle ku em gelek tiştan bi rengek xweşiktir, sade û pêbawer binivîsin, û dê piştgirî û domandina kodê hêsan bike. Û di wergerandinê de tiştek ecêb xuya dike, heke ne ji bo pîvana bingeha kodê û taybetmendiyên taybetî yên koda me be.
Ji bo kesên ku nizanin, 1C: Enterprise hawîrdorek e ji bo pêşkeftina bilez a serîlêdanên karsaziya cross-platform û dema xebitandinê ji bo pêkanîna wan li ser OS û DBMS-yên cihêreng. Bi gelemperî, hilberê dihewîne:
- , li ser Windows û Linux-ê dixebite
- , bi serverê re bi navgîniya http(s) an protokola xweya binary re dixebite, li ser Windows, Linux, macOS-ê dixebite
- , di gerokên Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari de dixebitin (bi JavaScript hatî nivîsandin)
- hawirdora pêşkeftinê (), li ser Windows, Linux, macOS dixebite
- pêşkêşkerên serîlêdanê, li ser Windows, Linux, macOS-ê dimeşînin
- , bi serverê re bi http(s) ve girêdide, li ser cîhazên mobîl ên ku Android, iOS, Windows dixebitin dixebite
- - çarçoveyek ji bo afirandina serîlêdanên desta yên negirêdayî yên bi şiyana hevdengkirinê, ku li ser Android, iOS, Windows-ê dixebitin
- jîngeha Pêşveçûn , bi Java hatiye nivîsandin
- Server
Em hewl didin ku bi qasî ku gengaz be heman kodê ji bo pergalên xebitandinê yên cihêreng binivîsin - bingeha koda serverê 99% hevpar e, bingeha koda xerîdar bi qasî 95%. Platforma teknolojiya 1C: Enterprise di serî de di C++ de hatî nivîsandin û taybetmendiyên kodê yên nêzîk li jêr têne dayîn:
- 10 mîlyon rêzikên koda C ++,
- 14 hezar dosya,
- 60 hezar dersan,
- nîv mîlyon rêbazên.
Û ev hemû tişt diviyabû ku di C++14 de werin wergerandin. Îro em ê ji we re vebêjin ka me ev çawa kir û di pêvajoyê de em bi çi re rû bi rû man.
Disclaimer
Her tiştê ku li jêr di derbarê xebata hêdî/lez de hatî nivîsandin, (ne) mezaxtina bîranîna mezin ji hêla pêkanînên dersên standard ên li pirtûkxaneyên cihêreng ve tê vê wateyê: ev ji bo ME rast e. Pir mimkun e ku pêkanînên standard dê ji bo karên we çêtirîn be. Me ji karên xwe dest pê kir: me daneyên ku ji bo xerîdarên me tîpîk bûn girtin, senaryoyên tîpîk li ser wan meşandin, li performansê, hêjmara bîranîna ku hatî xerckirin, hwd nihêrîn, û analîz kirin ka em û xerîdarên me ji encamên weha razî ne an na. . Û li gor wê tevdigerin.
Tiştê ku me hebû
Di destpêkê de, me koda ji bo platforma 1C: Enterprise 8 li Microsoft Visual Studio nivîsand. Proje di destpêka salên 2000-an de dest pê kir û guhertoyek me tenê Windows-ê hebû. Bi xwezayî, ji hingê ve kod bi rengek çalak hate pêşve xistin, gelek mekanîzmayên bi tevahî ji nû ve hatine nivîsandin. Lê kod li gorî standarda 1998-an hate nivîsandin, û, mînakî, kelûpelên meya rastê ji hêla cîhan ve hatine veqetandin da ku berhevkirin biserkeve, mîna vê:
vector<vector<int> > IntV;Di sala 2006-an de, bi berdana guhertoya platformê 8.1, me dest bi piştgirîkirina Linux-ê kir û veguherî pirtûkxaneyek standard a sêyemîn. . Yek ji sedemên derbasbûnê jî xebata bi xetên fireh bû. Di koda me de, em std::wstring, ku li ser bingeha wchar_t-ê ye, li seranserê bikar tînin. Mezinahiya wê di Windows-ê de 2 byte, û di Linux de standard 4 byte ye. Vê yekê rê lihevnehatina protokolên me yên binary di navbera xerîdar û serverê de, û hem jî daneyên cihêreng ên domdar. Bi karanîna vebijarkên gcc, hûn dikarin diyar bikin ku mezinahiya wchar_t di dema berhevkirinê de jî 2 byte ye, lê hingê hûn dikarin karanîna pirtûkxaneya standard ji berhevkerê ji bîr bikin, ji ber ku ew glibc bikar tîne, ku di encamê de ji bo wchar_t 4-byte tête berhev kirin. Sedemên din pêkanîna çêtir a çînên standard, piştgirîkirina tabloyên hash, û tewra emûlasyona semantîka guheztina hundurê konteyneran, ku me bi çalak bikar anî bû. Û sedemek din, wekî ku ew dibêjin dawî lê ne kêmasî, performansa string bû. Dersa me ya têlan hebû, ji ber ku ... Ji ber taybetmendiyên nermalava me, operasyonên string pir berfireh têne bikar anîn û ji bo me ev krîtîk e.
Rêza me li ser bingeha ramanên xweşbînkirina rêzikê ye ku di destpêka salên 2000-an de hatine vegotin . Dûv re, dema ku Alexandrescu li Facebookê xebitî, li ser pêşniyara wî, di motora Facebook-ê de rêzek ku li ser prensîbên wekhev dixebitî hate bikar anîn (li pirtûkxaneyê binêre ).
Rêza me du teknolojiyên xweşbîniyê yên sereke bikar anî:
- Ji bo nirxên kurt, tamponek hundurîn di cewhera rêzê de bixwe tê bikar anîn (ne hewceyî veqetandina bîranîna zêde).
- Ji bo hemî yên din, mekanîka têne bikar anîn . Nirxa rêzê li yek cîhek tê hilanîn, û di dema peywirdarkirin/guherandinê de jimarvanek referansê tê bikar anîn.
Ji bo lezkirina berhevkirina platformê, me pêkanîna tîrêjê ji guhertoya xweya STLPort (ya ku me bikar neanî) derxist, ev yek ji% 20 berhevkirina zûtir da me. Dûv re neçar ma ku em bi sînor bikar bînin . Boost, bi taybetî di API-yên karûbarê xwe de (mînakî, ji bo têketinê) giran bikar tîne, ji ber vê yekê me neçar ma ku wê biguhezînin da ku karanîna tîrêjê jêbirin. Vê yekê, di encamê de, ji me re dijwar kir ku em biçin guhertoyên nû yên Boost.
Rêya sêyemîn
Dema ku diçin standarda C ++14, me vebijarkên jêrîn nirxand:
- STLPort-a ku me li standarda C++14 guherand nûve bikin. Vebijêrk pir dijwar e, ji ber ku ... Piştgiriya STLPort di 2010-an de hate sekinandin, û em neçar in ku hemî koda wê bixwe ava bikin.
- Veguhastina pêkanîna STL ya din a ku bi C ++14-ê re hevaheng e. Pir tê xwestin ku ev pêkanîn ji bo Windows û Linux be.
- Dema ku ji bo her OS-ê berhev dikin, pirtûkxaneya ku di berhevkarê têkildar de hatî çêkirin bikar bînin.
Vebijarka yekem ji ber karê zêde bi tevahî hate red kirin.
Em demekê li ser vebijarka duyemîn fikirîn; wekî namzet tê hesibandin , lê wê demê ew di bin Windows-ê de nexebitî. Ji bo veguheztina libc++ ji Windows-ê re, divê hûn gelek karan bikin - mînakî, her tiştê ku bi têlan, hevdemkirina mijarê û atomîbûnê ve girêdayî ye bi xwe binivîsin, ji ber ku libc++ li van deveran tê bikar anîn. .
Û me rêya sêyemîn hilbijart.
Veguherîn
Ji ber vê yekê, me neçar bû ku karanîna STLPort-ê bi pirtûkxaneyên berhevkarên têkildar re biguhezînin (Visual Studio 2015 ji bo Windows, gcc 7 ji bo Linux, clang 8 ji bo macOS).
Xweşbextane, koda me bi giranî li gorî rêgezan hate nivîsandin û her cûre hîleyên aqilmend bi kar neaniye, ji ber vê yekê koça ber bi pirtûkxaneyên nû bi rêkûpêk bi rê ve çû, bi alîkariya nivîsarên ku li şûna navên celeb, çîn, cîhên navan û di çavkaniyê de vedihewîne. pelan. Koçberî bandor li 10 pelên çavkanî (ji 000) kir. wchar_t bi char14_t ve hate guherandin; me biryar da ku dev ji karanîna wchar_t berdin, ji ber char000_t 16 byte li ser hemî OS-an digire û lihevhatina kodê di navbera Windows û Linux de xirab nake.
Çend serpêhatiyên biçûk hebûn. Mînakî, di STLPort de îteratorek dikaribû bi nepenî li ser nîşanek ji hêmanekê re were avêtin, û li hin cîhên koda me ev hate bikar anîn. Di pirtûkxaneyên nû de êdî ev yek ne pêkan bû û diviyabû ku ev beş bi destan werin analîzkirin û ji nû ve binivîsin.
Ji ber vê yekê, koça kodê temam e, kod ji bo hemî pergalên xebitandinê têne berhev kirin. Dem dema ceribandinan e.
Testên piştî veguheztinê li gorî guhertoya kevn a kodê kêmbûnek performansê (li hin deveran heya 20-30%) û zêdebûna mezaxtina bîranînê (heta 10-15%) nîşan dan. Ev, bi taybetî, ji ber performansa nebaş a rêzikên standard bû. Ji ber vê yekê, em dîsa neçar bûn ku xeta xwe, hinekî hatî guheztin bikar bînin.
Taybetmendiyek balkêş a pêkanîna konteyneran di pirtûkxaneyên pêvekirî de jî hate eşkere kirin: vala (bê hêman) std::nexşe û std::set ji pirtûkxaneyên çêkirî bîranîn veqetîne. Û ji ber taybetmendiyên pêkanînê, li hin cihan di kodê de gelek konteynerên vala yên bi vî rengî têne afirandin. Konteynirên bîra standard hinekî têne veqetandin, ji bo yek hêmanek root, lê ji bo me ev yek krîtîk bû - di çend senaryoyan de, performansa me pir daket û mezaxtina bîranînê zêde bû (li gorî STLPort). Ji ber vê yekê, di koda xwe de me van her du celeb konteyneran ji pirtûkxaneyên çêkirî bi cîbicîkirina wan ji Boost-ê veguhezand, ku van konteyneran ne xwediyê vê taybetmendiyê bûn, û vê yekê pirsgirêk bi hêdîbûn û zêdebûna mezaxtina bîranînê çareser kir.
Wekî ku pir caran piştî guhertinên mezin ên di projeyên mezin de diqewime, dubarekirina yekem a koda çavkaniyê bêyî pirsgirêk nexebitî, û li vir, bi taybetî, piştgirî ji bo debugkirina îteratoran di pêkanîna Windows-ê de bi kêr hat. Em gav bi gav ber bi pêş ve çûn, û heya bihara 2017-an (guhertoya 8.3.11 1C: Enterprise) koçberî qediya.
Encam
Veguheztina standarda C++14 me nêzî 6 mehan girt. Pir caran, pêşdebirek (lê pir jêhatî) li ser projeyê xebitî, û di qonaxa paşîn de nûnerên tîmên berpirsiyar ên deverên taybetî tevlî bûn - UI, koma server, amûrên pêşkeftin û rêveberiyê, hwd.
Veguheztinê xebata me ya li ser koçkirina guhertoyên herî dawî yên standardê pir hêsan kir. Bi vî rengî, guhertoya 1C: Enterprise 8.3.14 (di pêşkeftinê de, serbestberdana ku ji bo destpêka sala bê hatî plansaz kirin) jixwe veguhestiye standardê .
Piştî koçberiyê, pêşdebiran vebijarkên zêdetir hene. Ger berê me guhertoya xweya guhertî ya STL û cîhek navek std hebû, naha me dersên standard ên ji pirtûkxaneyên berhevkar ên çêkirî li cîhê navên std, di cîhê navên stdx de hene - xetên me û konteynerên me ji bo karên me xweştir bûne, di zêdebûnê de - guhertoya herî dawî ya boost. Û pêşdebir wan dersên ku ji bo çareserkirina pirsgirêkên xwe bi guncan in bikar tîne.
Pêkanîna "xwecihî" ya çêkerên tevgerê jî di pêşveçûnê de dibe alîkar () ji bo çend dersan. Ger çînek xwedan çêkerek tevgerê be û ev çîn di konteynerek de were danîn, wê hingê STL kopîkirina hêmanên hundurê konteynerê xweşbîn dike (mînak, dema ku konteynir berfireh dibe û pêdivî ye ku kapasîteyê were guheztin û bîranîn ji nû ve veqetandin).
Kûçikek tar
Dibe ku encama herî ne xweş (lê ne krîtîk) a koçberiyê ev e ku em bi zêdebûna hejmê re rû bi rû ne. , û encama tevahî ya avakirinê digel hemî pelên navîn dest pê kir ku 60-70 GB digire. Ev tevger ji ber taybetmendiyên pirtûkxaneyên standard ên nûjen e, ku ji mezinahiya pelên karûbarê çêkirî kêmtir rexne bûne. Ev bandorê li operasyona serîlêdana berhevkirî nake, lê ew di pêşkeftinê de dibe sedema hejmarek nerehetiyan, nemaze, ew dema berhevkirinê zêde dike. Pêdiviyên cîhê dîska belaş li ser serverên çêkirinê û li ser makîneyên pêşdebir jî zêde dibin. Pêşdebirên me li ser çend guhertoyên platformê paralel dixebitin, û bi sedan gigabytes pelên navîn carinan di xebata wan de dijwariyan çêdikin. Pirsgirêk ne xweş e, lê ne krîtîk e; me çareseriya wê ji bo niha paşxist. Em teknolojiyê wekî yek ji vebijarkên çareserkirina wê dihesibînin (bi taybetî, Google dema ku geroka Chrome pêşve dike wê bikar tîne).
Source: www.habr.com