Twig: nopeuttaa sen mallien luomista
Verkkotoimisto » Digitaalisia uutisia » Twig: nopeuttaa sen mallien luomista

Twig: nopeuttaa sen mallien luomista

Äskettäin pyysin itseäni pohtimaan Twigin tarjoamia ratkaisuja kohteen tai taulukon ominaisuuksiin pääsemiseksi.

Objektin ominaisuuden käyttäminen

Twig on suunniteltu yksinkertaistamaan mallejamme sekä koodin että puhtauden suhteen. Se on myös suunniteltu mahdollistamaan integraattoreiden, ihmisten, joilla ei kaikilla ole kehitystietoa, helpon pääsyn kohteen tai muiden ominaisuuksiin. Tämä yksinkertaistetun syntaksin ansiosta.

Vasta sitten, ennen kaikkea kehittäjänä, esitin itselleni kysymyksen, kuinka twig selvitti, mikä menetelmä objektia pitäisi kutsua.

Twig-syntaksi

Seuraavassa koodissani oletan, että käytän alla olevan kaltaista luokkaa.

1
2
3
4
5
6
7
8
9
10
11
12
13
luokka objekti
{
yksityinen $Nimi;
julkinen $käyttäjänimi;
julkinen toiminto getName() {
palata $ tätä-> nimi;
}
julkinen toiminto hanki Käyttäjänimi() {
palata $ tätä->käyttäjätunnus;
}
}

Näin kutsun malliani Symfony-ohjaimesta.

1
2
3
julkinen toiminto indexAction() {
palata ryhmä("esine" => $objekti);
}

Toistaiseksi kaikki on selvää. Objektini näyttää täsmälleen samalta kuin objektit, joita voin käyttää projekteissani.

Jäsennysilmoitukset Twigissä

1
{{ object.name }}

Tästä eteenpäin näemme, kuinka Twig toimii puhelujemme kanssa. Tässä pyydämme Twigiä ottamaan arvon nimi Objektistani, paitsi että Twigille, joka on lopulta vain yksinkertainen PHP-kutsu, tämä muuttuja ei ole käytettävissä. Twig on siksi lisännyt välityspalvelimen, jolla voit tehdä abstrakteja ja nähdä, mitä ominaisuuksia ja menetelmiä on saatavilla.

Twig pyytää siksi alla olevassa järjestyksessä tarkastamaan kohteen.

  1. Katso jos objekti on matriisi ja jos nimi on avain;
  2. Katso jos objekti on esine ja jos nimi on käytettävissä oleva attribuutti;
  3. Katso jos objekti on esine ja jos nimi on menetelmä;
  4. Katso jos objekti on esine ja jos getName on menetelmä;
  5. Katso jos objekti on esine ja jos on nimi on menetelmä.
    Tässä käyttämillämme merkinnöillä jouduimme odottamaan 4. ehdon saapumista elementillemme. Koska nimi ei ole käytettävissä oleva attribuutti eikä menetelmä.

    1
    {{ object.username }}

Tässä tapauksessa yritämme päästä käyttäjätunnus. Tämä attribuutti on julkinen attribuutti (Symfonyssa törmäsin tähän tapaukseen harvoin). Meidän on odotettava toista ehtoa.

1
{{ object.getName() }}

Kolmannessa tapauksessa yritän kutsua menetelmääni suoraan. Saan tulokseni kolmannesta ehdosta, joka on nopeampi tila.

1
{{ object.getUsername() }}

Neljännessä ja viimeisessä tapauksessa yritän käyttää menetelmääni suoraan. Saan tulokseni kolmannesta ehdosta. Tässä tapauksessa asetin lisäehdon arvoani pääsylle.

Twig-mallien tulkitseminen

Kun katsoin tätä yksityiskohtaa, ajattelin, kuinka Twigin kehittäjät olisivat voineet tehdä mallien välimuistin ja kokoamisen. Ei kestänyt kauan, ennen kuin tulin siihen tulokseen, että pienellä tiedolla ja mallinhallinnan tarjoamalla vapaudella tiedostomme yksinkertaisesti kirjoitetaan PHP:ksi samalla tavalla kuin voisimme tehdä täysin. Voit myös nähdä itse katsomalla välimuistikansiota.

1
2
{# Mallihaara #}
{{ object.name }}
Malli tulkittu PHP:llä
1
echo twig_escape_filter($this->env, $this->getAttribute((isset($context["objekti"]) ? $context["objekti"] : $this->getContext($context, "object")), “nimi”), “html”, null, tosi);

Ensimmäinen lohko vastaa sitä, mitä huomasin oksamallissani, toinen lohko vastaa välimuistikansiosta löytämäni käännettyä versiota.

Huomaa, että haara on käännetty PHP:ksi, mutta mikään elementti ei ole antanut sen ennustaa, mitä menetelmää pitäisi kutsua tarkalleen. Menetelmä branch_escape_filter voidaan verrata välityspalvelimeen. Tällä menetelmällä määritämme, kuinka käytämme attribuuttia.

Yhteenveto

Vaikka Symfony tallentaa oksamallit automaattisesti välimuistiin, vain PHP-versio säilytetään, mutta ilman tulkintaa siitä, mitä haluat hakea. Teoriassa on siis olemassa keinoja optimoida puhelut ja malliemme generointiaika, koska varmennus suoritetaan jokaisessa puhelussa.

benchmark

Halusin silti saada käsityksen hyödyistä, joita voidaan saada kutsumalla menetelmiä mieluummin kuin " alias '.

Ensimmäisessä tapauksessa kutsun mallia, joka kutsuu 10 kertaa samaa objektia, joka puolestaan ​​kutsuu 25 aliasta. Tämä vastaa 250 puhelua. Tulokset suurennetaan 10:n silmukalla, jotta suorituskyvyn lisäys voidaan laskea tarkasti.

Toiseksi kutsun mallia, joka kutsuu samaa objektia 10 kertaa ja joka puolestaan ​​kutsuu 25 menetelmää (aina saman välityspalvelimen kautta kuin aliaksille). Se on taas 250.

Soitin näitä malleja 5 kertaa kutakin.

Huomaa, että kaikki kutsut malliin, jotka kutsuvat menetelmiä, ovat nopeampia. Ottamalla keskiarvot huomaamme, että aliaksia käyttävä malli on pidempi 54,6 millisekuntia (197.4 - 142.8).

Nopealla laskutoimituksella huomaamme, että jos pelkistämme sen yleiseen tapaukseen, menetelmäkutsuja käyttävä malli on samoilla tiedoilla keskimäärin noin 26.7 % nopeampi. Tämä voi olla mielenkiintoista, kun soitat useita objekteja.

Tämä toinen artikkeli seuraa ensimmäistä viestiä, joka tarjoaa nopeita ratkaisuja mallien luomisen optimoimiseksi. Se on optimoinnin hedelmä, jota on jo käytetty tuotantolaitoksissa, joilla oli liian korkea latenssinopeus.

Käytämme kaikki sisältää de Oksa muuttaa tai ottaa huomioon näkemyksemme. Mutta ehkä et koskaan ymmärtänyt, miksi meillä oli kyky välittää parametreja, kun perussisällys perii muuttujat nykyisestä kontekstista.

1
{% sisältää "ProjectMyBundle:Sub:template.html.twig" %}

Usein käytämme tätä merkintää. Tässä tapauksessa include antaa kopion kaikista muuttujistamme malliimme. Tämä ei ole aina välttämätöntä, ja olemme väärässä kopioiessamme kaikki muuttujamme.

"Ainoan" vaihtoehdon kiinnostus

Mietin pitkään, mikä tämän vaihtoehdon järkeä on. Lisäksi on sanottava, että dokumentaatio ei anna paljon tietoa. Voit katsoa Twig-dokumentaatiota. Se antaa vähän elementtiä, mutta se antaa erityisen haitan eikä etua: tulla toimeen ilman tiettyjä muuttujia. Tällä tavalla katsottuna se ei ole kannattavaa; miksi minun pitäisi tehdä ilman joitain muuttujia.

Toteutetaan osamme! Oletetaan, että perusmallissamme on 5 muuttujaa ja sisällytän mallin, joka käyttää vain yhtä näistä muuttujista. Tämä merkintä on parempi.

1
{% sisältää "ProjectMyBundle:Sub:template.html.twig", jossa on vain {"object": myVar} %}

Tällä tavalla vain "objekti"-muuttuja on käytettävissä mallissani. Tämä rajoittaa hyödyttömien muuttujien kopioimista ja siten muistin varaamista (säästöä aikaa ja muistin kulutusta).

Koodi ja käyttötapaukset

1
2
3
4
5
6
// Ohjain
// Tässä luo mallin välittämällä määräävän muuttujan (kokoelman), joka sisältää kaikki tietyn taulukon objektit
julkinen toiminto testAction() {
$objektit = $ tätä->container->get("doctrine.orm.default_entity_manager")->getRepository("ProjectMyBundle:Test")->findAll();
palata ryhmä("esineet" => $objektit);
}

Kierrämme kokoelmaamme ja annamme mallin jokaiselle kokoelman iteraatiolle mallille. Tässä tapauksessa joka kerta kun vaadimme mallin integrointia, kaikki muuttujat kopioidaan samoin kuin ne, jotka on välitetty "kanssa" -vaihtoehto. Ensimmäisessä tapauksessa voisimme hyvin kuvitella käyttävämme kokoelmaamme (objekteja) sekä nykyistä iteraatiota (objektia).

1
2
3
4
5
{#Malli 1#}
{% varten objekti objekteissa %}
{% sisältää "ProjectMyBundle:Sub:template.html.twig" ja {"object": object} %}
{% endfor %}

Toisessa tapauksessa aktivoin vaihtoehdon vain jonka avulla voit kopioida vain parametreina välitetyt muuttujat. Helppoa?

1
2
3
4
5
{#Malli 2#}
{% varten objekti objekteissa %}
{% sisältää "ProjectMyBundle:Sub:template.html.twig", jossa on vain {"object": object} %}
{% endfor %}

benchmark

Tein testit yllä olevassa osassa annetuilla malleilla ja koodilla. Tein 5 iteraatiota jokaiselle mallille, muistaen tyhjentää välimuistin ennen jokaista ensimmäistä testiä.

Tämän kaavion avulla voimme nähdä, että lataus on yleensä pidempi niille, jotka eivät käytä vaihtoehtoa vain. Ero pienenee välimuistin jälkeen. Tämä johtuu siitä, että mallini on pieni ja muuttujia käytetään vähän. Useimmissa tapauksissa voitot ovat jopa 30 %.

Tässä, jos laskemme arvojen keskiarvon, keskimääräinen ero on 9 ms (48,6 - 39,6 = 9). Voimme siis laskea likimääräisen 20 %:n voiton, vaikka tämä tarkasteltaisiin meidän tapauksessamme, koska ensimmäinen laukaus on hirveän pitkä ilman " vain '.

★ ★ ★ ★ ★