Dudum (in lapsu anni 2016) evolutionis proximae versionis 1C:Incepti technologiae suggestum, quaestio orta est intra turmas evolutionis de novo vexillo sustinendo in nostro codice. Transitus ad novum vexillum, sicut supposui, sineret nos multa elegantius, simpliciter ac fidenter scribere, et codicis sustentationem et sustentationem simpliciorem reddere. Atque in translatione nihil extraordinarium esse videtur, nisi ad basin codicis et notas proprias codicis nostri.
Pro iis qui non noverunt, 1C:Inceptum est ambitus ad celeris progressionis ascensionum negotiatorum applicationes et curriculi executionem in diversis OSes et DBMSs. In genere, producto continet:
- , currit in Fenestra et Linux
- , operando cum servo per http(s) vel protocollo suo binario, in Fenestra, Linux, macOS
- , currens in Chrome, Internet Explorer, Microsoft Edge, Firefox, navigatores Safari (JavaScript)
- Progressio environment () in Fenestra, Linux, macOS
- applicationes servers currunt in Windows, Linux, macOS
- , connectens cum servo per http(s), operatur in mobilibus machinis currentibus Android, iOS, Windows
- - compage conficiendi applicationes mobiles cum facultate synchronize, currit in Android, iOS, Windows
- Progressio environment , scriptum in Java
- servo
Eundem codicem scribere conamur pro diversis systematibus operantibus quam maxime - serviens basis 99% communis est, basis clientis circa 95% est. 1C:Inceptio technologiae suggestu principaliter in C ++ scriptae sunt et notae approximatae infra ponuntur:
- 10 decies centena millia linearum C ++ codicem,
- XIV milia files;
- LX milia asses,
- medium decies centena millia modi.
Quae omnia in C++14 transferenda erant. Hodie narrabimus tibi quomodo hoc fecerimus et quid in processu occurrimus.
Disclaimer
Omnia infra scripta de opere tardo/ieiunio, (non) magnae memoriae consumptio per exsequendam regulae classes in variis bibliothecis unam rem significat: hoc verum est PRO NOBIS. Fieri potest ut vexillum implementum aptissimum erit ad opera tua. Profecti sumus ab operibus nostris: notitias cepimus quae pro clientibus nostris typica erant, in missionibus typicis cucurrimus, spectavimus ad effectum, quantitatem memoriae consumpsit, etc., et enucleavimus utrum nos et nostri clientes talibus eventibus contenti sint necne. . Et fecerunt secundum.
Quod habuimus
Initio scripsimus codicem pro 1C:Inceptum 8 suggestum in Microsoft Visual Studio. Consilium in primis 2000s incepit et in Fenestra-tantum versionis habuimus. Utique, cum tunc codicem active enucleatum sit, multae machinae omnino revocentur. Sed Codex ad normam 1998 scriptus est, et, exempli gratia, angulus noster uncis rectis spatiis separatus est, ut compilatio succederet, hoc modo:
vector<vector<int> > IntV;Anno 2006, emissa versione suggesti 8.1, Linux favere incepimus et ad tertiam partem bibliothecae vexillum transivit . Una causa erat transitus latis lineis ad operandum. In nostro codice utimur std::wstring, quod in typo wchar_t innititur, per totum. Magnitudo in Fenestra 2 bytes est, et in Linux defectus 4 bytes est. Inde ad incompossibilitatem protocolla binarii nostri inter clientem et servitorem, necnon variae notitiae persistentes. Gcc optionibus utens, exprimere potes magnitudinem wchar_t in compilatione etiam 2 bytes esse, sed tunc oblivisci potes de utendo bibliothecae normae a compilatore, quod utitur glibc, qui rursus pro 4-byte wchar_t componitur. Aliae rationes meliores erant exsequendarum generum vexillum, subsidia tabularum hastarum, et etiam aemulatio semanticorum intra vascula movendi, quibus activo usi sumus. Et alia magis ratio, ut aiunt, ultima sed non minima, fiendi chorda fuit. Genus chordarum nostrarum habuimus, quia... Ob specialia programmatis nostri, operationes chordae valde late adhibentur et nobis hoc criticum est.
Nostra chorda fundatur in chordis optimizationis notiones expressas in primis 2000s . Postea cum Alexandrescu apud Facebook laboravit, eius suggestione linea adhibita est in machina Facebook quae similibus principiis laboravit (vide bibliotheca ).
Nostra linea duabus optimis technologiarum principalibus usus est:
- Pro brevibus valoribus, quiddam internum in ipso objecto chordarum adhibetur (additas destinatio memoriam non requirat).
- Omnibus aliis mechanicis adhibentur . Valor chorda in uno loco reponitur, et relatio calculi in assignatione / modificatione adhibetur.
Ad suggestum compilationem accelerandam, rivum exsequendum ab STLPort variantibus nostris (quo non utebamur) exclusimus, hoc nobis de 20% citius compilationem dedit. Postmodum limitata ad usum habuimus . Boost gravem usum fluminis facit, praesertim in ministerio APIs (exempli gratia, logging), ut ad usum fluminis removendum eam mutare debeamus. Id vicissim difficile nobis est ad novas Boost versiones migrare.
Tertio modo
Cum ad C++14 vexillum movens, sequentia optiones consideravimus:
- Upgrade STLPport vexillum C++14 modificatum est. Optio maxime impedit, quia... subsidium STLPort in 2010 disiunctum est, et nosmetipsos totum codicem suum aedificare volumus.
- Transitus ad aliam STL exsecutionem compatitur cum C++14. Valde optandum est ut haec exsecutio pro Fenestra et Linux sit.
- Cum pro singulis OS componendis, bibliotheca utere constructa in compilator respondente.
Pri ex option reicienda ornes nimis laboramus.
De secunda optione aliquamdiu cogitavimus; considerari ut candidatum sed tunc non laborabat sub Fenestra. Ad libc ++ ad Fenestram, multum opus facere debes - exempli gratia, scribe omnia tibi quae cum filis, filo synchronisationi et atomicity, quia libc++ in his locis usus est. .
Et nos ter- viam elegimus.
Selenium
Itaque usum STLPort reponere habuimus cum bibliothecis compilariorum respondentium (Visual Studio 2015 pro Fenestra, gcc 7 pro Linux, clang 8 pro macOS).
Fortunate codex noster maxime secundum normas scripsit et omnibus artificiis artificiis usus non est, migratio ad novas bibliothecas faciliter processit, ope scriptorum quae nomina typorum, generum, nominum et in eo fonte substituta sunt. imagini. Migratio 10 fontium fasciculorum affectus (ex 000). wchar_t substitutum est per char14_t; usum wchar_t relinquere decrevimus, quia char000_t accipit 16 bytes in omnibus OSes et codicem compatibilitas inter Windows et Linux non corrumpit.
Parva quaedam fuerunt casus. Exempli gratia, in STLPort iterator implicite potest obiciatur ad monstratorem elementi, et in nonnullis locis in codice nostro hoc adhibitum est. In novis bibliothecis id facere amplius non licebat, et haec loca enucleanda et manually rescripta erant.
Ita, signum migrationis completum est, signum pro omnibus systematibus operantibus exaratum est. Praesent tempus volutpat.
Expertus post transitum ostendit guttam in effectu (in aliquibus locis usque ad 20-30%) et augmentum memoriae consumptionis (usque ad 10-15%) comparatum cum vetusta versione codicis. Hoc praesertim ob chordarum vexillum suboptimal effectus. Ergo iterum uti debemus, linea leviter mutata.
An interesting feature of the implementation of containers in embedded libraries was also manifest: vacua (sine elementis) std::map and std::set from built-in libraries allocate memory. Et ob exsequendam lineamenta, nonnullis in locis in codice satis multa vasa vacua huius generis creantur. Continentiae apocryphae memoriae parum partita sunt, pro una radice elementi, sed nobis hoc evenit ut critica - in pluribus missionibus, effectus noster omisso insigniter ac memoria consummatio aucta (comparatur STLPort). In nostro igitur codice has duas continentiarum genera ex constructis in bibliothecis suis deducendis a Boost reposuimus, ubi haec continentia hanc notam non habebant, et hoc problema tarditatis et memoriae consummationis augebatur.
Ut saepe accidit post magnas commutationes in magnis inceptis, prima fontis codicis iteratio sine problematibus non laboravit, et hic, praesertim, subsidium debugging iteratores in Fenestra exsequendum in promptu venit. Gradatim promovimus et fonte 2017 (versio 8.3.11 1C:Incepti) migratio completa est.
results
Transitus ad C++14 vexillum circiter VI menses nos suscepit. Frequentius, unus (sed valde idoneus) elit in incepto laboravit, et in ultimo gradu iunctorum repraesentantium responsales certis locis iunctis - UI, servo botri, evolutionis et administrationis instrumentorum, etc.
Transitus valde simplicior nostrum opus est migrandi ad recentissimas normas vexillum. Ita, versio 1C:Inceptio 8.3.14 (in evolutione, emissione pro primo anno proximo accedendo) iam ad vexillum translatum est. .
Post migrationem tincidunt plura bene. Si antea nostram versionem STL mutatam haberemus et unum std spatiorum nominamus, nunc habemus regulas normas ex bibliothecis constructis in compilatoris in spatio nominali std, in spatio nominali stdx - lineis et vasis nostris optimized ad munia nostra, in boost - the postremam versionem boost. Et elit utitur illis generibus quae ad solvendas difficultates optime aptae sunt.
In "patria" exsecutionem motus conditorum adiuvat etiam in evolutione () per plures classes. Si genus movens fabricatorem habet et hoc genus in vase ponitur, STL optimizat exemplaria elementorum intra continentem (exempli gratia, cum dilatatur continens et necesse est mutare facultatem ac memoriam reallocare).
In fugere ista unguenti
Consecutio migrationis gravissima fortasse (sed non critica) est quod obvium est cum augmento voluminis ac plenum effectum aedificiorum cum omnibus fasciculis intermediis 60-70 GB capere coeperunt. Mores iste ob proprietates recentiorum bibliothecarum vexillum, quae minus criticae magnitudinis imaginum servitutis generatae factae sunt. Quae operatio non pertinet ad applicationem digestae, sed causat compluras incommoda progressus, praesertim, auget compilationem temporis. Requisita gratis spatii orbis terrarum in ministris aedificandis et in machinis elit crescentibus sunt. Nostrae tincidunt operantur in pluribus versionibus machinis in parallelis, et centeni gigabytarum imaginum intermediarum interdum difficultates in opere suo creant. Quaestio est iniucunda, sed non critica: solutionem eius nunc distulimus. Consideramus technologiam unam ex optionibus solvendis (praesertim Google eo utitur cum pasco Chrome enucleans).
Source: www.habr.com