Inĝenieroj de Cloudflare, Mozilla, Facebook kaj Bloomberg nova formato por akceli la liveron kaj prilaboradon de JavaScript-kodo dum malfermado de retejoj en la retumilo. BinaryAST movas la analizan fazon al la servila flanko kaj liveras jam generitan abstraktan sintaksarbon (). Ricevinte BinaryAST, la retumilo povas tuj iri al la kompila stadio, preterirante analizi la JavaScript fontkodon.
Por testado referenca efektivigo liverita sub la MIT-licenco. Node.js-komponentoj estas uzataj por analizado, kaj la kodo por optimumigo kaj AST-generado estas skribita en Rust. Retumilo-flanka subteno
BinaryAST jam haveblas en Fajrovulpo. La kodilo en BinaryAST povas esti uzata ambaŭ ĉe la fina retejo-ila nivelo kaj por pakaj skriptoj de eksteraj retejoj flanke de prokura aŭ enhavo-livera reto. Nuntempe, la procezo de normigado de BinaryAST de la laborgrupo jam komenciĝis , post kio la formato povos kunekzisti kun ekzistantaj enhavkunpremaj metodoj, kiel gzip kaj brotli.
Dum prilaborado de JavaScript, signifa kvanto da tempo estas elspezita en la ŝarĝo kaj analiza fazo de la kodo. Konsiderante, ke la volumo de elŝutita JavaScript en multaj popularaj retejoj estas proksima al 10 MB (ekzemple, por LinkedIn - 7.2 MB, Facebook - 7.1 MB, Gmail - 3.9 MB), la komenca prilaborado de JavaScript enkondukas gravan prokraston. La analiza stadio ĉe la retumila flanko ankaŭ malrapidiĝas pro la malkapablo plene konstrui la AST sur la flugo dum la kodo estas ŝarĝita (la retumilo devas atendi ke kodblokoj kompletigu ŝarĝon, kiel la fino de funkcioj, por akiri la informoj mankantaj por analizi la nunajn elementojn).
Ili provas parte solvi la problemon distribuante la kodon en minimumigita kaj kunpremita formo, kaj ankaŭ per konservado de la generita bajtokodo de la retumilo. En modernaj retejoj, la kodo estas ĝisdatigita sufiĉe ofte, do kaŝmemoro nur parte solvas la problemon. WebAssembly povus esti solvo, sed ĝi postulas eksplicitan tajpadon de la kodo kaj ne taŭgas por akceli la prilaboradon de ekzistanta JavaScript-kodo.
Alia opcio estas liveri pretan kompilitan bajtkodon anstataŭ JavaScript-skriptoj, sed programistoj de retumilo-motoroj kontraŭas ĝin ĉar triaparta bajtkodo malfacilas kontroli, ĝia rekta prilaborado povas konduki al TTT-tavoliĝo, pliaj sekurecriskoj estiĝas, kaj la evoluo de universala bajtkoda formato estas postulata.
BinaryAST permesas vin alĝustigi al via nuna koda evoluado kaj liveromodelo sen krei novan bajtkodon aŭ ŝanĝi la JavaScript-lingvon. La grandeco de datumoj en la formato BinaryAST estas komparebla al kunpremita minigita JavaScript-kodo, kaj la pretiga rapideco per forigo de la fonta teksto-analiza fazo pliiĝas rimarkeble. Krome, la formato permesas kompilon al bajtokodo kiam BinaryAST estas ŝarĝita, sen atendi ke ĉiuj datumoj finiĝos. Krome, analizado ĉe la servilo ebligas ekskludi neuzatajn funkciojn kaj nenecesan kodon de la resendita BinaryAST-reprezento, kiu, analizante ĉe la retumila flanko, malŝparas tempon kaj analizante kaj transdonante nenecesan trafikon.
Karakterizaĵo de BinaryAST estas ankaŭ la kapablo restarigi legeblan JavaScript kiu ne estas ĝuste la sama kiel la originala versio, sed estas semantike ekvivalenta kaj inkluzivas la samajn nomojn de variabloj kaj funkcioj (BinaryAST konservas nomojn, sed ne konservas informojn pri pozicioj en la kodo, formatado kaj komentoj). La alia flanko de la monero estas la apero de novaj atakvektoroj, sed laŭ la programistoj, ili estas multe pli malgrandaj kaj pli kontroleblaj ol kiam oni uzas alternativojn, kiel ekzemple bytecode-distribuo.
Testoj de la facebook.com-kodo montris, ke analizado de JavaScript konsumas 10-15% de CPU-resursoj kaj analizado prenas pli da tempo ol generado de bajtokodo kaj komenca kodogenerado por JIT. En la SpiderMonkey-motoro, la tempo por tute konstrui AST prenas 500-800 ms, kaj la uzo de BinaryAST reduktis ĉi tiun ciferon je 70-90%.
Ĝenerale, por plej multaj retfajraĵoj, kiam vi uzas BinaryAST, JavaScript-analiza tempo malpliiĝas je 3-10% en la reĝimo sen optimumigo kaj je 90-97% kiam la reĝimo ignori neuzatajn funkciojn estas ebligita.
Dum funkciado de 1.2 MB JavaScript-testaro, uzi BinaryAST permesis al la ektempo plirapidiĝi de 338 ĝis 314 ms sur labortabla sistemo (Intel i7) kaj de 2019 ĝis 1455 ms sur poŝtelefono (HTC One M8).
fonto: opennet.ru