Discussioni template:Tabella breve

Il meccanismo del template

Nella versione iniziale il template fa due cose:

1. apre un testo <style=" all'inizio del template e lo chiude con un "> alla fine del template;
2. nella parte centrale del template chiama per 10 volte il template secondario {{Tabella breve/parse}}, inviandogli uno alla volta i parametri per l'eventuale traduzione da forma abbreviata a forma "normale".

Siano i parametri 1 o 10, siano costituiti da abbreviazioni o no, il template secondario viene comunque chiamato 10 volte o_O. In una tabella un po' corposa, diciamo di 50 celle con il template, ci sono quindi 500 chiamate al template secondario (non va bene).

Esaminiamo adesso come funziona il template secondario, che è basato su un semplice #switch (scelta fra opzioni multiple).

Innanzitutto il template esamina se gli è stato passato un parametro; in caso contrario non fa niente.

Se gli è stato passato un parametro, scorre, una alla volta, tutte le possibilità, dall'alto al basso; alla prima corrispondenza restituisce il codice che segue il carattere = e salta il resto; prima di uscire aggiunge un punto e virgola.

Una ripassata al codice #switch fa capire l'astuzia dei "sinonimi". Esaminiamo la prima riga fra le scelte dello #switch:

• |right|align right|right align|ar=text-align:right

Questo significa che qualsiasi parametro right, align right, right align oppure ar viene comunque "tradotto" in text-align:right.

Se scorse tutte le righe e tutti i sinonimi, il template non ha trovato alcuna corrispondenza esatta con il parametro, restituisce semplicemente il parametro come sta (condizione finale #default={{{1}}}). Nella tabella ipotizzata prima, con 50 celle con il template, il povero sottotemplate /parse esegue (a occhio i sinonimi sono un centinaio) 500*100 =50000 confronti o_O.

Il fatto che il template principale accodi tutte le risposte dentro a un attributo style crea una incompativilità con la contemporanea presenza, "esterna" al template ma nello stesso tag html (es. nella stessa cella) di un altro attributo style, in chiaro o generato da un altro template.

Questa è la situazione di partenza: vediamo di migliorare le cose (magari in un altro template geralizzato che sfrutti poerò la stessa idea e con la stessa "elasticità"), che potrebbe chiamarsi semplicemente {{Style}} associato a un redirect chiamato {{Stile}}. --Alex brollo (disc.) 16:57, 11 gen 2018 (CET)

1. mi piace la tua lucida analisi. c'è qualche riscontro sul discorso di una esigenza miglior efficienza del wikicode nel template ? ovvero se i server sono potenti e sottoutilizzati, uno potrebbe dire chissenefrega trovare la soluzione perfetta, certo se ho un'idea di saper fare una bella Ferrari per tutti ben venga, ma se non la so fare, probabilmente non succede niente se una macchina lavora un po' di più. L'umano si adatta, mentre lavora si fa una polpetta o reindirizza i suoi sforzi in maniera multitasking. Vorrei vedere come vedi probabilmente tu dove sta il problema vero ... mi faccio capire ?

2. hai già un'idea di come progettare bene un {{Style}} ... ne possiamo parlare, se posso ti dò una mano, programmare mi piace e mi dà soddisfazione ...possiamo anche costruirci una discussione complessa a 4 mani ... tieni conto che di codice magari sarò ancora un po' diesel per un po' ...

3. poi, resti tra noi, mi piacerebbe riuscire a fare il codice perfettino, elegante, essenziale, ben fatto etc e magari poi continuare a farlo

4. c'è inoltre un modo per misurare l'efficienza di due template, degli strumenti che alla fine permettono di dire, il job con questo template dura 0.83 10-6 secondi, con quell'altro 10 secondi ... ? come si fa ? :MauC66 (disc.) 00:39, 12 gen 2018 (CET)

@MauC66 Per avere un'idea complessiva della complessità della pagina come impegno dei server, basta aprire la finestra "view sorce" dell'html in visualizzazione. Dentro due commenti ci sono parecchi parametri di controllo; aprendo una pagina a caso ottengo ad esempio questa robaccia:

<!-- 
NewPP limit report
Parsed by mw1268
Cached time: 20180112075814
Cache expiry: 1900800
Dynamic content: false
CPU time usage: 0.000 seconds
Real time usage: 0.004 seconds
Preprocessor visited node count: 3/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 0/2097152 bytes
Template argument size: 0/2097152 bytes
Highest expansion depth: 2/40
Expensive parser function count: 0/500
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00%    0.000      1 -total
-->

Molto tempo fa, quando ho "sistemato" il template Loop, ho rivevuto un grosso complimento da Tim Starling (esagerato!) che conservo orgogliosamente nella mia pagina utente: «This is exactly the kind of optimisation that competent editors like you can and should be doing.» Ovviamente questa cosa mi ha incoraggiato a prendere sempre in considerazione la possibilità di ottimizzare. Tim ha lavorato su Lua (Scribunto) proprio per evitare le inefficienze del codice template, in casi come questi (pesanti #switch). : Io vedo due possibili miglioramenti del codice template:

1. evitare che il sottotemplate sia chiamato "a vuoto" quando sono finiti i suoi parametri;
2. evitare che il sottotemplate debba scorrere l'intera lista dei possibili parametri, se il contenuto del parametro non è "abbreviato"Alex brollo (disc.) 09:16, 12 gen 2018 (CET)

Per poter usare il template all'interno di un template che già crea stile, basta ideare un ulteriore parametro che "dica" al template di NON aggiungere, in testa e in coda, il codice style="....">; facendo così l'output del template potrà essere "incorporato" dentro un codice style, accodando le "sue cose" alle dichiarazioni css già presenti. Un bell'esercizio :-)

non sembra così difficile, moh ci provo. lieto di aver inquadrato la faccenda. poi magari ci lavoriamo insieme. MauC66 (disc.) 11:22, 12 gen 2018 (CET)

altre idee da verificare

altre idee potrebbe essere trovare degli algoritmi per migliorare il meccanismo di selezione ed estrazione dall'elenco delle sintassi complete per la direttiva di stile scelta. l'elenco può essere utile perchè semplifica all'utente con una semplice scelta al posto di dover ogni volta produrre i comandi e le sintassi giuste. Cosa fare dipende un po' da quello che abbiamo disponibile. MauC66 (disc.) 16:25, 12 gen 2018 (CET)

Ho importato il modulo:String . Con questo si può fare un pensierino su come ridurre la complessità di trovare un algoritmo per la scelta della direttiva giusta analizzando la stessa. Valutandone lunghezza, scomponendola in lettere ... vediamo come fare MauC66 (disc.) 17:15, 12 gen 2018 (CET)

lista con l'abbreviazione come indice di posizione

Creando una lista dei comandi di stile css con le abbreviazioni a chiamarle come indici c'è una corrispondenza immediata tra chiamata e testo css completo richiamato, senza bisogno di tante (155) valutazioni. Credo che questa sia la scelta migliore. Che ne dici ? MauC66 (disc.) 18:14, 12 gen 2018 (CET)

Prova2

@Alex brollo

Sto lavorando sul template Prova2... Ho ad esempio creato un sottotemplate begin e uno end che separano style=" e " dal corpo dell'elenco dei css.

"siano i parametri 1 o 10"

Vediamo, se ci capisco bene: vedi IF "Se la condizione consiste in una stringa vuota o uno spazio, allora è considerata falsa,". Se i parametri successivi al 1 non ci sono il parse non dovrebbe partire o fermarsi al primo if subito falso se non c'è il parametro. E' vero che c'è 1| ma è anche meglio, l'if è falso basta che i parametri siano vuoti o nulli. Pensavo di mettere a protezione dei parametri successivi degli if con i parametri successivi ma credo non serva quindi. vedi guida Chiarito che i parametri successivi non vengono valutati si può estendere anche a più di 10 parametri senza tema di appesantire troppo. :MauC66 (disc.) 14:36, 12 gen 2018 (CET)

"...incompatibilità..."

come mostrano le mie prove di cui all'inizio, è perfettamente separabile la direttiva in apertura (style=") e chiusura (") e la lista di proprietà css selezionate. Possiamo creare un template style con solo la parte elenco, di selezione dell'elenco, e poi unirlo magari con due trasclusioni di style/begin e style/end (o a "mano") o al volo entro un altro style.

"...sinonimi..."

la mia conoscenza del linguaggio wiki non è così approfondita, più che sinonimi dovrebbe trattarsi di stessi casi switch senza = che quindi fanno capo all'ultima assegnazione con l'=, quello dell'ultimo. Vedi switch . MauC66 (disc.) 16:26, 12 gen 2018 (CET)

"...a occhio i sinonimi sono un centinaio..."

sono 155 alternative

"...pesanti switch..."

viceversa credo che lo switch sia molto leggero e che forse hai scambiato un'assegnazione per un confronto. In pratica quello che fa lo switch è immagazzinare tra i suoi case tutta una serie di possibilità, poi quando entri con un 'case' salta a quel case se c'è altrimenti va al case di default; una volta al 'case' giusto ritorna al trascluso il valore a destra dell'uguale, il parametro espanso di stile. Credo che creare un vettore con indice gli stili abbreviati e il contenuto i parametri di stile estesi, non faccia niente di più che lo switch, ma la struttura, funzioni, tabella vettoriale etc credo sia molto più pesante. Quindi non saprei selezionare funzione più veloce di uno switch come selettore. Se infatti creiamo un modulo che disseziona in entrata lo stile concentrato in lettere e poi prende decisioni su quella base, credo non migliori sia la memoria che il numero di operazioni. Se hai altre idee idee sono tutt'orecchi.  :MauC66 (disc.) 19:49, 12 gen 2018 (CET)

Conclusioni

Permettimi quindi di saltare alle conclusioni.

Credo quindi tb o Tabella breve sia ampiamente ottimizzato, veloce, facilmente implementabile aggiungendo stili utili, e via dicendo. Che mi dici ora ? MauC66 (disc.) 19:49, 12 gen 2018 (CET)

Come vedo io la cosa

1. d'accordo sulla facilità di evitare il codice style (si può pensare di renderlo opzionale oppure di costruire un template "parallelo" che non lo aggiunga, pur avendo la stessa logica; preferirei la prima soluzione).
2. la valutazione dei parametri può essere realizzata (nel template principale) con if annidati che "escano" non appena i parametri sono terminati. In tal modo il template secondario sarebbe chiamato solo per il numero dei parametri effettivamente esistenti.

 
{{#if: {{{1|}}}
   | {{tb/breve|{{{1|}}}}} {{#if: {{{2|}}}
       | {{tb/breve|{{{2|}}}}} {{#if: {{{3|}}}
            | {{tb/breve|{{{3|}}}}} .......
            }}
       }}
}}

1. il problema dello switch è abbastanza serio; può essere migliorato in due modi:
   1. prevedendo, per i "sininimi", anche le forme in "linguaggio naturale" (attualmente l'algoritmo restituisce il codice "naturale" che gli è stato passato solo dopo aver completato senza successo l'intero set di confronti);
   2. ordinando le alternative in modo che quelle più frequenti siano in testa alla lista (in modo che lo switch le trovi rapidamente).

Questo se si vuole lasciare pressochè intatta la logica del template; le cose cambiano radicalmente se si sostituisce il "motore" con Scribunto, che possiede potenti funzioni di elaborazioni di stringa e implementa dizionari molto efficenti.

In questo caso:

1. l'elenco di tutti i codici o loro abbreviazioni potrebbe essere passato con un solo parametro, semplicemente stabilendo un carattere separatore (e mi pare che il carattere separatore ideale sia il punto e virgola);
2. lo script farebbe innanzitutto uno "split" del parametro separando i vari elementi;
3. per ogni elemento lo script consulterebbe un semplice dizionario "traducendo", se serve, l'abbreviazione nel suo codice naturale; la ricerca per indice in un dizionario è altamente ottimizzata.

Operativamente proporrei di costruire in qualche pagina provvisoria una versione della famosa tabella "difficile" per cui ti ho fatto i miei complimenti, e un template di prova (in un secondo momento un modulo Scribunto di prova); di trasformare tutti i codici cs in chiamate al template di prova; e poi di esaminare l'effetto analizzando gli eventuali miglioramenti della performance con la risposta del server. Esistono degli "hackeraggi" per cui al codice template vengono attribuite possibilità di manipolazione di stringhe, ma a detta di Tim sono estremamente inefficienti, e vanno accuratamente evitati. Al momento eviterei di modificare Template:Tb che forse non è ideale come performance ma funziona bene - noli me tangere.

Modificando solo il codice template la sintassi di chiamata resterebbe identica; convertendo in Lua invece cambierebbe da {{ts|ar|ba|sc}} a {{ts|ar;ba;sc}}

Esiste un'alternativa per passare valori multipli in un solo parametro con il codice template, l'abbiamo sperimentato all'interno del terribile template Intestazione per permettere, se necessario, di inserire più di un autore nel campo singolo Autore. Sfrutta #titleparts, funzione che nasce per spezzettare i nomi pagina, e in questo caso il separatore deve essere il carattere /. Resta però il problema del numero massimo di "spezzettamenti", mentre la conversione in Lua con split non avrebbe tale limitazione (oltre a avere un codice molto più semplice e leggero)

Alex brollo (disc.) 05:10, 13 gen 2018 (CET)

Non capisco

Non capisco bene alex. Il problema dell'if a quanto pare l'abbiamo risolto e abbiamo ridotto la complessità di 1/10 e possiamo metterci anche più parametri. Il problema dello style anche. Per lo switch non capisco. Non capisco se il problema è che i template e i moduli sono inefficienti e con essi le istruzioni in essi contenute. Ovvero se la stessa cosa fatta in lua ovvero scribunto non è più inefficiente ma efficiente, se il problema è lo script del template. In tal caso basta copiare il template parse in un modulo, tradurlo in lua e chiamarlo al posto del template. Nella mia esperienza di programmatore non ho mai sentito che un'istruzione base fondamentale come switch è 'inefficiente' perchè per arrivare a uno dei suoi n casi memorizzati deve fare n confronti di stringa. Dico, è una istruzione fondamentale di ogni linguaggio e non ho mai sentito di sostituirla con qualcosa di più efficiente o con un algoritmo. E' come se mi dicessi che se ho un vettore[1000], se chiamo vettore[999] è inefficiente perchè prima di darmi il 999esimo elemento devo fare un confronto tra tutti gli indici fino al 999simo e che quindi invece di usare tale notazione devo inventarmi un programma per farlo. Ora per i vettori è abbastanza facile si fa indirizzo+999 ma ci sono vocabolari con indici lessicali, ad esempio vocabolario['casa'] mi trova l'elemento 'casa' e mi ritorna la stringa ivi memorizzata. Ma non ho mai sentito che ciò sia inefficiente e devo inventarmi un programma per farlo. Probabilmente c'è già, ovvero c'è una mappa che associa a 'casa' un indirizzo e quindi chiamando casa ho subito l'indirizzo che mi serve senza fare una ricerca o un confronto come dici tu tra tutte le stringhe. Inoltre mostrami dove sta questa cosa dei sinonimi, ti ho girato i link dei manuali ma non li hai guardati, non sono sinomimi ma casi senza assegnazione che fanno capo al primo che ha l'assegnazione. E' come nei linguaggi mettere case:'1'; case:'2'; case:'3': istruzione3; break; tutti i casi 1, 2 3 tre fanno capo a istruzione3. Qui via testo ci si fa fatica a capire. Forse è meglio una videoconferenza o una chat, hangout o simili, stiamo a scrivere un sacco di cose ma è un dialogo che non ci si capisce. MauC66 (disc.) 17:46, 13 gen 2018 (CET)

In lua non c'è. Lo switch si può comunque sostituire con una serie di if http://lua-users.org/wiki/SwitchStatement .  MauC66 (disc.) 18:05, 13 gen 2018 (CET)

Potresti usare il modulo string che ho importato. Crei un modulo parse o con un determinato nome e poi invece di chiamare il template /parse chiami il modulo, scritto in lua, che magari fa la scomposizione per lettera dei parametri etc etc. Una volta che hai finito vorrei vedere però se le statistiche ti danno ragione e l'efficienza in una tabella complessa è aumentata. Per le prove puoi generare un Alex_Brollo/Sandbox ... . Di solito una buona ottimizzazione di ricerca del case suddivide l'intero elenco successivamente in 2 parti (sono gli algoritmi utilizzati da gcc "Optimizing compilers such as GCC or Clang may compile a switch statement into either a branch table or a binary search through the values in the cases)") oppure control tables MauC66 (disc.) 18:46, 13 gen 2018 (CET)

Il lua può usare il c. Utilizzi lo switch del c, lasci che il compilatore ottimizzi, poi lo tiri dentro con il lua che può gestire c. MauC66 (disc.) 19:13, 13 gen 2018 (CET)

Ah, parlo con un programmatore vero....! Bene, adesso mi è chiaro il motivo della tua velocità di apprendimento, averlo saputo subito non ti avrei trattato come un principiante..... Io non lo sono. Sono un orecchiante autodidatta. Ma ti ripeto: ricordo che Scribunto è stato ideato proprio per aggirare le inefficenze del codice template, che NON è un vero linguaggio di programmazione e che NON è in grado per esempio, a meno di pesanti hackeraggi, di fare una cosa banale come la ricerca o l'estrazione di sottostringhe. In particolare, un serio problema server era determinato proprio da pesanti #switch, che sono il sistema più intelligente per cercare di emulare un dizionario dentro un codice template (parola di Tim Starling). Comunque, sul codice e sulla teoria a questo punto mi ritiro in buon ordine: ubi major minor cessat. Torno alla tipografia. Alex brollo (disc.) 07:30, 14 gen 2018 (CET)

Modulo lua StyleVoc

@Alex_brollo Prova questi in una pagina di test: {{#invoke:StyleVoc|vocabulary|right}} {{#invoke:StyleVoc|vocabulary|justify}}

Sono la versione senza switch. Se ti piacciono si tratta di mettere in tabella lua gli altri 155 . Poi di vedere se il codice è più efficiente. In pratica in un template style puoi per ogni parametro, bloccandoli come si è detto con un if, invocare il modulo per il parametro in modo che ti ritorna la stringa al posto del parametro breve, e crea la stringa completa di style, poi puoi farne cosa vuoi inserendola in cella o in tabella. Ti soddisfa ? MauC66 (disc.) 00:48, 14 gen 2018 (CET)

Mi pare un buon inizio. Con un colpo di excel ho costruito e inserito il dizionario completo; annulla se ho sbagliato a interpretare la tua intenzione. Buon lavoro. --Alex brollo (disc.) 08:06, 14 gen 2018 (CET)

@Alex_brollo hai fatto un ottimo lavoro naturalmente. ... Se ti può capitare sono molto utili anche gli editor in cui è possibile selezionare il testo con un rettangolo qualsiasi, sui bordi, al centro, dove vuoi, ma excel va anche bene, anch'io talvolta me ne giovo. Ho visto che negli align hai tolto qualcosa, forse era sbagliato o inessenziale, in questo sei giudice. Scusa se nelle risposte talvolta ho seguito un percorso personale di crescita, ho cambiato opinione, magari mi sono accaldato, mi sono stupito, talvolta è difficile spiegarsi o capirsi o si capisce una cosa per un altra ... Mi piacerebbe ora fare un test, troviamo una tabella abbastanza complicata e rivoluzioniamola. Credo si possa usare tb o tabella breve per finire il lavoro che abbiamo cominciato, poi magari utilizziamo Template:Prova2 invece per vedere Table style vecchia versione con lo switch e vedere se abbiamo guadagnato qualcosa, di memoria o di velocità. Puoi farlo e copiare qui i risultati ? Grazie. MauC66 (disc.) 11:45, 14 gen 2018 (CET)

Fine

@Alex_brollo ho finito la modifica di Tabella breve o tb. Mi pare non ci siano errori. In pratica il template, usando StyleVoc, crea la stringa di stile. Ho scelto poi la via più semplice ovvero ho lasciato fuori testa style=" e coda " in modo che la stringa di style trasclusa può essere aggiunta a style preesistenti, oppure si può aggiungere in modo semplice ulteriori stili di cui sia necessario. Non resta ora che scegliere una tabella complicata e quindi fare le statistiche per testimoniare che un risultato c'è stato, usando tb e Prova2 (vecchia versione di Table Style) . Che mi dici ? MauC66 (disc.) 12:45, 14 gen 2018 (CET)

@MauC66 Le cose sono cambiate passando da codice template a Lua: ti propongo un ulteriore passo, chiamare StyleVoc una sola volta passandogli in blocco i parametri, e lasciando che la verifica di esistenza o no dei parametri la faccia il codice dello script. Meglio una chiamata sola che una sequenza di chiamate. Scribunto è molto efficiente e flessibile, una volta che è avviato. --Alex brollo (disc.) 13:38, 14 gen 2018 (CET)

@Alex_brollo fatto! Non è ancora molto elegante in lua perchè zoppico, ne so poco ma magari in futuro... . Ho incluso in lua tutti i 10 parametri anche se poi da template chiama i singoli parametri solo se singolarmente non nulli e presenti. Dovrebbe funzionare. Se va bene manca:

1. trovare la tabella complicata
2. fare i test con tb e con Prova2 per vedere i guadagni effettivi di velocità e memoria

Sono curioso, facciamolo ! MauC66 (disc.) 15:17, 14 gen 2018 (CET)

@MauC66 In realtà dovrebbe bastare iterare sulla tabella degli argomenti. Ma devo ristudiarmi Lua ogni volta che ci metto mano :-(. Un utente che attende inutilmente da tempo che qualcuno affronti alcune "tabelle complicate" è @Silvio Gallio, ce ne fornirà parecchie: Silvio, ci ripeti un paio di link alle tue incompiute-a-causa-di-tabelle-impossibili"? Così uniamo l'utile al dilettevole :-) --Alex brollo (disc.) 16:32, 14 gen 2018 (CET)

Uhm dopo tanti anni... Mi pare che siano quei testi rimasti nella lista in pagina utente Utente:Silvio Gallio; di certo quelli contengono tabelle, Non so quanti difficili e mi pare che qualcuna sia stata sistemata ma non SALata? (qualche testo con un paio di pagine/tabelle si porta almeno al 75%)

(volevo fermarmi qui ma poi ho dato un'occhiata) Confermo. Sono esse. Credo cjhe le peggiori siano:

• Indice:Relazione sulla scelta della linea di allacciamento delle ferrovie italiane col Gottardo.djvu
• Indice:Delle strade ferrate italiane e del miglior ordinamento di esse.djvu
• Indice:Rivendicazione della primitiva linea di Strada Ferrata da Milano a Venezia.djvu

Se non vi bastano andate in pagina utente Utente:Silvio Gallio in alto c'è la lista. :)

Le altre nel gruppo "al 50%" hanno problemi di formattazione che forse si risolvono con tabelle

Questa : Indice:Milani - Risposta a Cattaneo, 1844.djvu l'avevo completamente dimenticata. Non so se ci sono tabelle (non mi stupirebbe) ma direi che sia meglio che ci lavori sopra prima io. [con questo non pongo limiti alla Provvidenza, eh! :)] - Quelle al 75%, devono solo essere rilette. Ma non temete, se trovo qualcosa di utile sarà mia cura balzarvi addossso :D Silvio Gallio (disc.) 18:13, 14 gen 2018 (CET)

Test

@MauC66 Intanto ho copiato la tabella "da cui tutto inizia" in Utente:Alex brollo/tabella con cs, adesso la copio in Utente:Alex brollo/tabella con prova2 e dovrebbe essere facile sostituire i cs con chiamate a Prova2, dopodichè proviamo Tb "luato". Vedi che ho copiato i tempi performance dalla sorgente pagina. --Alex brollo (disc.) 16:56, 14 gen 2018 (CET)

ottimo. io farei anche uno con tb tabella breve Utente:Alex brollo/tabella con tb. Sarà poi da valutare come ripulire o aggregare quello di rotazione se non va trattato in maniera separata e particolare.

Se non erro:

<div style=" 
   {-webkit-transform: rotate(90deg); /* Safari and Chrome and Android browser */
    -moz-transform: rotate(90deg);   /* Firefox */
    -ms-transform: rotate(90deg);   /* IE 9 */
    -o-transform: rotate(90deg);   /* Opera */ </code>
    transform: rotate(90deg);}" ></div>

Per passare da cs a tb:  CS   -> equivalente tb

trbl  bordati top right bottom left   ->  bt br bb bl
TMB vertical-align Top Middle Bottom -> vtp vmi vbm
LCR  text-align Left, Center, Right  -> al ac ar

MauC66 (disc.) 17:22, 14 gen 2018 (CET)

Ho trovato dei fastidi nel trasformare il codice da prova2 a tb; per stasera lascio. --Alex brollo (disc.) 20:58, 14 gen 2018 (CET)

Dirittura finale

Caro @Alex brollo, ho fatto il seguente lavoro. 4. Utente:Alex brollo/tabella con tb ho sostituito in toto, sia per {{Cs}} che per per {{Rot1}} il nuovo {{tb}} ovvero per {{Tabella breve}}. E' stato un lavoraccio, ora puoi vedere una tabella più compatta e spero che le statistiche che copierai ci daranno già un bel risultato.

Poi pensavo di passare a Prova2 ma ci avevi nel frattempo lavorato già tu. Ho deciso di lasciare come stava. Per vedere meglio il confronto con {{tb}} ho pensato di modificare un po' Prova2, allora l'ho ricopiato in {{Prova3}} per poter fare delle modifiche senza rompere quanto già avevi fatto. Le modifiche fatte per renderlo tb compatibile erano di togliere /begin ed /end perchè tb era solo stringa senza i tag di stile. Inoltre ho aggiunto rot in /parse, come avevo fatto in tb per poterlo sostituire anche a rot1. Infine avrei dotuto copiare in una tabella con tb ma ho pasticciato con le tante tab ed è qui 3. Utente:Alex brollo/tabella con prova 2.

Le altre statistiche che hai già fatto vanno bene, grazie e stanno in 2. Utente:Alex brollo/tabella con prova2 quelle con il {{Prova2}} che hai sistemato tu, e 1. quello di partenza con Utente:Alex brollo/tabella con cs

Il quadro dovrebbe poi essere completo e ci potrebbe permettere di continuare e prendere altre decisioni di ottimizzazione :MauC66 (disc.) 23:30, 14 gen 2018 (CET)

Caro @Alex brollo, qual'è il tuo responso, nè carne nè pesce ? leggi tu per me, che non sono pratico, se abbiamo ottimizzato in qualche senso ... dimmi poi in quale senso dobbiamo ancora lavorare MauC66 (disc.) 23:56, 14 gen 2018 (CET)

Confrontando cs, prova2 e tb, i rispettivi "real time" sono 0.130, 0.288 e 0.242 secondi. Sono deluso, mi aspettavo molto di più dalla "luizzazione". Sembra che l'elemento critico sia il numero di chiamate a template, e che conti meno il codice template vero e proprio a ogni singola chiamata, di cui i server se ne fanno un baffo. Buono a sapersi.

Bè, anche se il risultato non è stato brillante, qualcosa abbiamo imparato :-)

Una cosa prevedibile, ma carina lo stesso da verificare, è che in tutti e tre i casi ci sono 0/500 "Expensive parser function count". --Alex brollo (disc.) 00:05, 15 gen 2018 (CET)

Caro @Alex brollo, prova a fare il test di 3. Utente:Alex brollo/tabella con prova 2. dove è utilizzato il {{Prova3}} e va in parallelo con la tabella fatta con tb, sono stati tolti tutti i cs e rot. Resta quindi soltanto una trasclusione di Prova3 con l'aiuto del suo /parse. :MauC66 (disc.) 00:13, 15 gen 2018 (CET)

Fatto! Ho trovato anch'io nel codice del sorgente le statistiche. Prova3 ha un tempo di 0.202 sec. Non resta che riflettere ed eventualemente fare ulteriori prove. MauC66 (disc.) 01:06, 15 gen 2018 (CET)

@MauC66 In questo caso il responso è: le differenze di performance sono pressochè irrilevanti. Diventa quindi preminente la comodità per l'utente. Se comunque vuoi approfondire la questione "maneggiamento dati in Lua" ci sono due filoni:

1. la separazione fra dati e script che li usa, mettendo i dati in moduli-contenitore specializzati (lo usiamo nell'accrocchio "Modulo:Dati/...." attivabile per ogni pagina Indice e utilizzato prevalentemente dal template Pg; che io sappia, è un "unicum" di it.source);
2. la possibilità di importare/esportare da Lua in formato JSON, molto promettente perchè permetterebbe di utilizzare facilmente i dati anche in Javascript (non ancora utilizzata da noi). Alex brollo (disc.) 11:06, 15 gen 2018 (CET)