TLE (e non solo) su PCW

Ff300

fanbase Nintendo =/= fanbase Pokémon
Wiki
Premessa: in questo topic verranno trattati solo aspetti puramente tecnici. Se non sei admin puoi anche non leggerlo.

Come forse avrete notato sempre più spesso ci troviamo delle pagine che esplodono perché ci sono troppi template/moduli (per esempio i recenti problemi con il nuovo template Squadra e con alcuni elenchi). In questo topic vorrei investigare le cause e proporre soluzioni.

tl;dr: leggiti l'ultimo paragrafo.

Parte 1: le origini
Contenuto della sezione: come MediaWiki decide di far esplodere le pagine (è una sezione tecnica e si può saltare)

In primo luogo vorrei sottolineare che esistono più motivi per cui una pagina può esplodere: per la precisione MediaWiki tiene 10 contatori mentre parsa (trasforma il WikiCode nell'HTML servito agli utenti) una pagina, e se uno di questi contatori supera un certo limite il parsing viene "mozzato" nel senso che si rifiuta di aumentarli ancora (con effetti diversi a seconda del contatore). Li potete vedere mentre modificate una pagina:
3278
Quelli che interessano a noi sono essenzialmente 2: "dimensione inclusioni post-espansione" e "tempo di utilizzo Lua". Il primo è responsabile per i "la dimensione dei template inclusi supera il limite consentito" (il problema del template Squadra) e ha come effetto che i template non vengono più espansi, lasciando il codice {{nometemplate|args...}}. Il secondo è il responsabile dei "il tempo per l'esecuzione dello script è scaduto" (quando ci sono troppi moduli in una pagina, in breve). Quest'ultimo lo indicherò con TLE (time limit exceeded) per brevità.

Il tempo di utilizzo Lua dovrebbe essere chiaro cos'è e come viene calcolato. In generale non abbiamo moduli talmente pesanti da eccedere quel limite (i moduli singoli più pesanti, gli elenchi automatici, dovrebbero aggirarsi sui 2/3 secondi), quindi se viene superato è perché ci sono troppe chiamate a moduli nella pagina. La cosa importante da sapere qui è che tante chiamate da WikiCode costano molto di più un'unica chiamata ad un modulo che poi fa internamente le stesse chiamate.

La dimensione inclusioni post-espansione è più difficile da capire; vi spiego quello che ho capito io ma potrebbe essere sbagliato. In breve ogni volta che un template viene espanso questo contatore aumenta della dimensione dell'output del template, anche se il template è incluso da un template incluso dalla pagina. Questo significa che so ho una pagina che contiene {{A}} e la pagina template:A contiene solo {{B}}, il contenuto espanso di {{B}} conterà due volte nel limite della pagina (una volta per l'espansione di B all'interno di A e una volta nell'output di A). Questo significa anche che se faccio {{A|param={{B}} }} e il template:A contiene solo {{{param|}}} il contenuto di {{B}} conterà comunque due volte (l'espansione nella pagina e il fatto che il suo contenuto, passato come parametro ad A, compaia nell'output di {{A}}). In realtà credo ci sia un po' di più ma la sostanza dovrebbe essere questa.
Riferimento

Parte 2: cosa interessa a noi?

Contenuto della sezione: cosa vogliamo fare per evitare che le pagine esplodano

In primo luogo dobbiamo capire quando questi limiti sono un problema e quando invece segnalano una pagina effettivamente troppo pesante. Per esempio il template Squadra è molto pesante sulle dimensioni post-espansione perché usa dei sottotemplate molto grossi (essenzialmente il Pokémon, che a sua volta usa i MoveBox) ma non credo sia un problema perché effettivamente vogliamo evitare pagine con troppi template squadra (perché diventano enormi e pesantissime). Viceversa per i moduli di solito il TLE indica, come già spiegato prima, che ne vengono inclusi troppi in una pagina piuttosto che un vero problema di pesantezza della stessa. Di questo secondo caso ho parlato proprio stamattina con Maze e non siamo davvero giunti ad una conclusione. Il problema si presenta quasi esclusivamente con gli elenchi perché avendo qualche centinaio di entry, ognuna con 3-4 chiamate a moduli "piccoli" (quei moduli che si invocano direttamente da WikiCode per avere un piccolo output, per esempio MiniSprite, CSS, Blakcabbrev o PokémonData) si fa in fretta a fare troppe chiamate. Viceversa è difficile che si presenti in altre pagine perché non si hanno invocazioni massicce di moduli.

A questo proposito dobbiamo quindi distinguere due tipi di template (perché alla fine sono loro che usano i moduli e quindi causano il problema): quelli intesi per uso in pagine "standard" (con un numero di moduli limitati, ovvero più o meno tutti i non-elenchi) e quelli per uso in pagine "costose" (con molti moduli, gli elenchi). Per i primi io incentivo molto l'utilizzo di moduli piccoli (non ditemi che non volete usare il MovesData per il template Pokémon ed evitare di passare tipo e categoria danno oltre al nome della mossa) perché non dovrebbero causare problemi. Per le pagine costose il discorso cambia molto, e a me vengono in mente solo due soluzioni:
1 - limitare al minimo indispensabile l'utilizzo di moduli piccoli nelle entry; che vuol dire, per esempio, niente PokémonData per sostituire parametri con nome e tipi o niente gradienti all'interno delle entry (lo sfondo bianco va benissimo).
2 - rendere tutti gli elenchi dei moduli, molto semplici ma in modo da trasformare un elenco in un'unica invocazione. Questo risolve il problema del TLE.
Ovviamente entrambe le soluzioni presentano evidenti svantaggi. La 1 vuol dire limiti nel fare gli elenchi, che sia di grafica o di comodità d'uso. Per dire, il VexEntry su cui ho lavorato ieri e oggi non so neanche se si riesce a fare in questo modo perché utilizza Blackabbrev e Colorabbrev in modo strutturale. La 2 vuol dire che ci vuole qualcuno capace di fare un modulo dai template delle entry, che è un lavoro che richiede il suo tempo, e che se c'è da fare un quick fix bisogna comunque aspettare me o Maze. Ho fatto un paio di moduli per elenchi recentemente e ci vuole qualche ora di lavoro, per quanto sia un compito abbastanza meccanico. Inoltre gli elenchi vecchi sono tanti, quindi per recuperarli tutti ci corrà molto tempo.

Quindi volevo sapere da voi quanto siete disposti a ridurre eventuali moduli negli elenchi in favore di implementazioni più lightweight contro la vostra disponibilità a trasformarli in moduli (con i problemi che ne conseguono). Ovviamente se alla luce della mia spiegazione vi vengono in mente altre soluzioni ben venga.
 

CiaobyDany

あなたと見る絶望は あなた無しの希望など霞むほど輝くから
Wiki
Ovviamente non sono minimamente in grado di fornire nuove soluzioni, ma prima di prendere una decisione vorrei capire una cosa. Il lavoro di trasformazione degli elenchi in moduli, che tu hai definito "abbastanza meccanico", è plausibile che possa essere fatto anche da noi, tutto o più presumibilmente in parte? Cioè, mi immagino che una volta che mi metti la struttura esterna e un paio di entry poi dovrebbe essere fattibile aggiungere altre entry via similitudine (cfr modulo colore o sigle data in cui posso metterci le mani senza grossi problemi anche se nessuno me li ha mai spiegato). A seconda della risposta a questo interrogativo la situazione credo cambi drasticamente.
 

Lucas992X

Senza gli apici
Wiki
Per gli elenchi, io valuterei caso per caso. Tendenzialmente però sono favorevole a trasformarli direttamente in moduli, perché così verrebbero automaticamente aggiornati ad ogni modifica dei moduli dati e non dovremmo praticamente più preoccuparcene.
 

Ff300

fanbase Nintendo =/= fanbase Pokémon
Wiki
È una domanda che mi sono posto anch'io ieri. Fare un nuovo elenco secondo me si può riuscire, soprattutto perché fatti uno o due tipi "base" gli altri sono più o meno tutti uguali o comunque formati da "pezzi" presi da questi. Se poi ci mettiamo ad usare una nomenclatura standard per certe cose (esempio: con "p" si accede ai parametri) secondo me il codice dovrebbe risultare abbastanza comprensibile. Alla peggio posso riempirli di commenti. Sicuramente però creare una nuova entry è molto più difficile che aggiungere un colore o una sigla.

La cosa di trasformarli in moduli automatici è l'obbiettivo finale ma con molti non si può perché non c'è un modulo dati e in generale io mi risparmierei di farlo se serve solo per quell'elenco. Per esempio per il VexEntry (Pokémon esclusivi di una versione) non c'è un modulo dati e secondo me è poco utile farlo. Ovviamente dove possibile l'idea è di farlo (e a questo scopo l'Evo-data dovrebbe aiutare molto perché è pieno di elenchi in cui serve sapere se A è un'evoluzione di B per calcolarli in automatico).
 

Lucas992X

Senza gli apici
Wiki
A tal proposito, un rapido semi-OT: visto che abbiamo il modulo dati per gli strumenti tenuti a sto punto potremmo anche inserirlo nelle pagine dei singoli Pokémon al posto dell'attuale template, o no?
 

Maze

TypoMzn
Wiki
Arrivo con ben due settimane di ritardo, ma
A tal proposito, un rapido semi-OT: visto che abbiamo il modulo dati per gli strumenti tenuti a sto punto potremmo anche inserirlo nelle pagine dei singoli Pokémon al posto dell'attuale template, o no?
Eh, qui si incorre nel TLE. Se hai un modulo tipo PokémonData ma per gli strumenti, lo chiami millemila volte ed è un macello. La cosa migliore è fare un modulo grosso, a cui si passa il nome del Pokémon e sputa fuori la tabella WikiCode.
 

CiaobyDany

あなたと見る絶望は あなた無しの希望など霞むほど輝くから
Wiki
Arrivo con ben due settimane di ritardo, ma

Eh, qui si incorre nel TLE. Se hai un modulo tipo PokémonData ma per gli strumenti, lo chiami millemila volte ed è un macello. La cosa migliore è fare un modulo grosso, a cui si passa il nome del Pokémon e sputa fuori la tabella WikiCode.
Credo che fosse quello che intendeva Luca in realtà (o almeno, io avevo interpretato così)
 

Lucas992X

Senza gli apici
Wiki
Intendevo proprio quello :D una cosa del tipo (nome a caso)
Codice:
{{#invoke: helditems | {{PAGENAME}} }}
che restituisca tutta la tabella con gli strumenti tenuti nei vari giochi.
 
Top Bottom