S'han disparat els missatges de temps exhaurit per l'execució d'scripts. Ex.: Estats Units d'Amèrica.
Pot tenir a veure amb el canvi d'ahir de Wikidata ? La infotaula no s'ha tocat des del 3/8. Ja sé que va justeta, però ara envia 20 missatges seguits
Possiblement, quantes més coses afegeixen més justos anem.
Substituint {{Taula d'estat}} per {{Infotaula geografia política}}, sense paràmetres, entra la infotaula i l'error de temps exhaurit surt més avall. Caldrà migrar d'una a l'altra.
En una previsualització, l'apartat "Elements Wikidata utilitzats en aquesta pàgina" espanta. La darrera vegada que ho vaig comprovar, per treure "Etiqueta" no consumia recursos, però sí els accessos arbitraris on diu "Declaració".
Caldrà pensar en fer retallades dràstiques. D'entrada em carregaria totes les llistes amagades. Si s'amaguen no són del tot útils. En versió per a mòbils surten desplegades i cal tirar molt avall per trobar la introducció.
Si el canvi només ha incrementat, doncs res, el que cal mirar és la infotaula. Només era per prudència que no estigués en bucle.
El tema etiquetes, la meva idea era tenir replicades les etiquetes locals a /labels i només accedir a WD si lang no local. Però això no evitaria l'expansió de la plantilla GetLabelFix.
El tema dels desplegable, hem de demanar un consens amb la comunitat on jo proposaria tallar la llista (no sé encara com) si és superior a X i treure sempre desplegades les inferiors. Treure els desplegables és suportable si són llistes "normals", però cal tenir una solució per les llargades patològiques.
Hi ha forma barata de saber quantes instàncies hi ha d'una propietat abans de tractar-lo ?. Estava mirant que USA té una brutalitat de "conté", "fet significatiu" i "membre de". Crec que podríem "penalitzar els excessius", sense haver de penalitzar tothom.
He creat una funció:
Ja l'he aplicat a {{infotaula geografia política}} per no mostrar la llista de municipis d'una regió/departament,.. si són +10. Cascava a Meurthe i Mosel·la que en té: 568
Per tant, quan vulguis ho pots passar a producció
L'he posada a Mòdul:Wikibase perquè és una subfunció de mw.wikibase.getAllStatements.
Ara he vist el que passa amb les pre-infotaules. Quan vaig crear infotaula geografia política, hi havia centenars de infotaules amb noms diferents. Les que tenien menys articles les vaig migrar a mà i les grans, vaig encarregar un bot al @Joutbis que, si bé va ser exitós en altres migracions, en les d'aquesta infotaula mai hem trobat el moment per executar-lo i fer net, perquè el control de qualitat posterior roba temps. Intuint que el 80% dels paràmetres manuals no servirien per res, vaig posar en les pre-infotaules un accés a la property equivalent en tots els candidats a inútils i, si existia contingut a WD, no copiava el paràmetre manual per a que quan entrés la infotaula de veritat, ho agafés de WD. Per tant, tenim un grapat de dobles accessos.
Com que no compto que el @Joutbis s'hi animi a dedicar el seu agost a fer aquesta feina, modificaré les preinfotaules per a què posin en una categoria tots aquells articles que no tenen res a aprofitar i així ja sabrem que en aquests podem entrar a sac a eliminar-les.
Això del numStatements gasta poc, oi?, perquè en el 90% dels casos serà una pregunta estèril, ja que seran pocs i, per tant, li vindrà darrera l'accés al contingut.
Merci,
En aquest cas dels EUA ja pots fer la migració manual, continua donant error però es recupera una mica. Així es pot anar delimitant el problema.
El numStatements és una consulta simple amb una funció de wikibase. Estic per posar-la al Mòdul:Wikibase com a subproducte. Com tot, no gasta si no s'usa amb accés arbitrari, amb un item diferent al de la pàgina.
Als EUA ja li he tret la infotaula estat i he anul·lat manualment el "fet_clau" i "part_de" que tenien un munt d'entrades, i encara dóna error.
{{taula d'estat}} desactivada. Ja he migrat tots els articles.
Però hi ha mines més perilloses, com {{Infotaula del municipi català}} que fa servir #ifexist: Media.
La bona notícia és que he fet una andròmina per migrar manualment relativament ràpid. Més info a la discussió d'en Pau
Ja veurem.
Provant en l'article dels EUA, hi ha tres infotaules: la política, la d'economia i la de demografia. La política gasta:
Suposo que les crides a getEntity són accessos arbitraris. En aquest cas: Mont McKinley, Donald Trump i Economia dels EUA. L'altitud del McKinley no crec que variï i es pot evitar amb un paràmetre altitud_màxima=6.190 o bé afegint-ho com a qualificador tal com està el punt més baix.
La d'economia gasta:
Aquí és on dóna ara l'error, el temps sumat ja supera els 10s, la memòria els 50M. Sorprèn que gasti tanta memòria i crides a getEntity. D'entrada, la {{Infotaula economia país}} té un paràmetre item que no s'usa i un paràmetre item_pais que l'obté suposant que estem en l'article Economia dels Estats Units i no en l'article del país. Tal com està definit no puc fer proves en una altra pàgina, no puc veure quins són els accessos arbitraris. (He descobert que l'apartat "Elements Wikidata utilitzats en aquesta pàgina" no mostra les dades de la previsualització sinó les dades de l'article desat, cosa que em feia tornar boig). De fet, sembla que la infotaula sigui redundant tenint un article principal. La mateixa infotaula en l'article de l'economia i amb dades més completes només gasta:
El més fàcil serà carregar-se-la en lloc d'intentar caçar mosques. Dels 10 articles de països on s'usa en 3 exhaureix el temps Lua. Tot i així, repassa com usa els paràmetres item.
Per completar l'anàlisi, la de demografia gasta:
Mira aquesta prova de la subplantilla de generació de codis estadístics. Segur que podré rascar alguna cosa (algun if then show..).
Això està en el primer bloc
Lo d'economia és kafkià, i suposo que haig d'assumir la paternitat perquè així ho diu l'historial, tot i que em sembla que ja m'ho devia trobar mig muntat. Anyway.
Per entendre com es compten en aquest cas els accessos arbitraris: Tenim que els accessos es fan des d'una subplantilla; si jo li passo un valor en "item" i als invoke no els hi poso res, compten com a normals, tot i que l'item de l'article sigui un altre ?. Si és així, l'invent dels dos items s'ha de muntar al revès, ja que el nombre d'accessos a dades de l'article d'economia són mínims.
Tot i pensar que està al revès, el seu lloc original era l'article de l'economia. La presència en una secció dels articles de l'estat, quan una part de les dades ja s'ha mostrat a la infotaula principal, no té sentit.
Les dades d'economia són a l'item del país, no a l'item d'economia. Es faci com es faci, en l'article del país seran accessos directes i en l'article d'economia seran accessos arbitraris.
Tant a l'article dels EUA com el d'economia, es queda amb item_pais buit perquè cap dels dos no té la Aspecte de (P1269). Amb el paràmetre item no en fa res perquè la subplantilla /prepara no l'usa, les invocacions es fan amb item_pais i com que està buit pren per defecte l'item de la pàgina. Fixa't que en l'article d'economia la plantilla sense cap paràmetre treu una infotaula buida, no treu cap dada de Wikidata.
En l'article dels EUA sospito que gasta tant per culpa del formatting=unitcode, però no puc provar res sense un paràmetre que em permeti provar-ho en una altra pàgina.
Suposo que es tracta de quedar-se només amb un paràmetre item, el corresponent a l'economia, i consultar en aquest cas Estat (P17) o el que toqui. Caldrà veure com està estructurat, per exemple a Economia de Catalunya (Q2879009) no hi ha cap P. Amb això empitjorarà aquesta infotaula amb accessos arbitraris i per això cal provar què passa als EUA amb accessos directes.
Pots provar-ho cridant directament {{Infotaula economia país/presenta|item_pais=Qnnnnn}}. De fet, {{Infotaula economia país}} només fa un trasllat literal de paràmetres. Em penso que me la carregaré, perquè no aporta cap valor excepte el d'intentar infructuosament passar-li la Q del país. Per cert, la propietat més adient seria la Jurisdicció (P1001). M'espero que em diguis alguna cosa per començar amb els canvis.
Merci
Ok, doncs no acabo d'entendre que l'economia gasti quasi tanta memòria com la política, tot i que sigui més ràpida. No són accessos arbitraris, no és el getEntity que ara veig que és % de temps i per tant és menor en valor absolut. No és la quantitat d'invocacions, l'economia en té la meitat. Només em queda pensar que l'economia consulta molts qualificadors. Comprovar la diferència entre consultes de propietats i consultes de qualificadors, en les mateixes condicions, resultarà complicat. Una altra possibilitat és que la previsualització m'estigui enganyant perquè hi hagi implicats cachés de Lua que no es netegen.
En qualsevol cas, tira endavant. Canvia-la com vulguis i fora infotaules d'economia en estats que tinguin article principal.
Hola Vriullop i @Paucabot. Avui ha tornat a donar problemes la {{IGP}} amb l'article d'Alemanya. Ara està apagat el foc perquè he desconnectat una part del codi poc útil, en concret, les dades econòmiques que habitualment només estan a nivell de país i ens ho podríem estalviar en molts cassos. En tot cas, haurem de podar altres coses per poder recuperar la part econòmica precisament als articles que més consumeixen que semblen ser els de països.
Estic fent una versió de prova a Plantilla:Amadalvarez/traduccions_2 mirant de millorar codi. He descobert que cridem a plantilla:xarxes que fa les icones i enllaços a xarxes socials. El codi el varem renovar fa poc amb el @Paucabot que és qui ha anat posant-la al dia de les noves aparicions.
Fent un previsualitzar en una crida directa i autònoma amb la Q d'Alemanya (Q183) que no té cap xarxa, consumeix: 2,4s, 24M; i amb Shakira (Q34424) que té 13 XS, dóna 0,8s, 3,82M. Es pot entendre el perquè d'aquesta contradictòria diferència ?. Tenint en compte que el codi és fixe i repetitiu, seria més òptim si es fes en LUA ?. @Paucabot, podríem reduir les XS a tractar ?, moltes deuen ser minoritàries i les tenim per tothom igual.
Merci,
Si s'ha d'esporgar el tema de les xarxes, s'esporga. Però, amb les dades que dones, diria que no hi ha res que faci pensar que són el culpable de la situació.
@Paucabot de fet, amb les dades de la (petita) mostra hauríem de demanar tothom que s'apunti a totes les XS !!, però tinguem-ho present, per si de cas.
@Vriullop Pot ser que afecti tant al resultat la mida de l'ítem que estem consultant ?. Ho dic perquè els temps que dóna {{xarxes|item=Qnnn}} accedida directament són força diferents per casos similars (municipis sense XS):
La memòria ja ho entenc i no és massa diferent amb tot el codi IGP (32,63M per Q183 i 8,56M per Q1492), però la CPU creix molt.
2a prova: he fet que només s'executi la capa de dades de IGP i, enlloc de cridar a la capa de presentació (IGP/formatglobal), no crido res i surten totes les dades una darrera l'altra sense formatar tal com les deixa IGP.
Els resultats són ( a les 7 am d'avui, ja que veig que la CPU hn baixat respecte ahir a la tarda):
És a dir que l'aportació de formatar és relativament baix.
3a prova: executar directament {{Infotaula geografia política/codis geogràfics }}; és una subplantilla per triar un grup de codis estadístics. Agafa un parell d'internacionals i un altre parell de locals. Pensava que el codi era optimitzable quan vaig provar Alemanya, però en la línia del cas de "xarxes", he fet una prova més gran:
Ok, problema gros. He provat sobre:
Amb un consulta simple {{#invoke:Wikidata | claim | property=P30 | item=Q183}} dona:
Sembla que la mida de l'element fa que consumeixi més recursos. Si repeteixo la mateixa consulta 5 vegades:
No multiplica per 5 però ja consumeix la meitat dels 50 Mo màxims.
Com que em sembla increïble per a una consulta simple, he anat a fer la mateixa prova a l'anglesa. Amb {{#invoke:Wikidata | getValueFromID | Q183 | P30 | FETCH_WIKIDATA}} els resultats són similars. Ara bé, a l'anglesa tenen més d'un mòdul Wikidata. Aquest parteix de la mateixa estructuració que el nostre. Provant amb un altre, {{#invoke:WikidataIB | getValue | qid=Q183 | P30 | fetchwikidata=ALL | onlysourced=false}} els resultats són diferents, de 750 Ko tant per Alemanya com per Andorra, cosa més normal. I si ho repeteixo 5 vegades són 1 Mo també en els dos casos.
Això és una impugnació a la totalitat. Hauré d'estudiar què fa el mòdul WikidataIB que sigui més eficient que el mòdul Wikidata. Això portarà temps, cosa que no tinc en els propers 15 dies. Em temo que per algun motiu van fer un mòdul tot nou per a Wikidata InfoBox.
Coll...s. Quina diferència. Crec que sabrem esperar-te. Per la meva part, poliré tot el que pugui el codi wiki i acabaré amb les multilingües ara que sembla que no és consumidor el getlabel. Si et cal alguna cosa, alguna prova, demana. Quan hi hagi novetats, seguim en aquest fil.
Ara ho dic jo: coll..s! Resulta que tindrem sort. He sortit a comprar i mentre anava passejant he tingut una aparició esotèrica. Li anava donant voltes a que el Lua profile de la previsualització diu que la major part de recursos són del getEntity. Això és una funció que obté totes les dades de l'element, una passada per a Alemanya. Hi ha una altra funció que obté directament una propietat, i he comprovat que així és com ho fa l'anglès WikidataIB. Substituint-la sembla que s'arregla tot plegat. Comproveu bé la versió en proves amb diferents plantilles, que això afecta directament al moll de l'os.
Val. I recuperar cada propietat una a una, no penalitzarà l'accés i, amb això la CPU i el temps total ?. Bé, vaig a fer proves.
@Paucabot@Vriullop Mostra ràpida de resultats a Usuari:Amadalvarez/taules2.
La primera conclusió és que:
en tot cas, sempre són inferiors les xifres. Bona eina, Vicenç !
Si voleu fer més proves, la {{Amadalvarez/traduccions 2}} es una versió d'IGP amb wikidata/proves.
Mòdul actualitzat, és una millora important i el que em preocupava és que no sortissin errors.
Mira que fa temps que li donàvem voltes. La clau ha estat veure el comportament de Xarxes a Alemanya quan no havia de fer res.
Han desaparegut uns quants articles de la categoria d'errors. Ara queda pendent:
En proves hi he afegit un límit màxim de 50 en llistes, un valor arbitrari, i llavors funciona sense error i sense la llista
Corregides: {{indret}}, {{Infotaula edifici}} i {{Infotaula persona}}
Em miraré aquests casos. També haurem de limitar els premis que, en algunes organitzacions, són moltíssims.
Ara que estem posats en el tema llistes, es podria passar al mòdul el màxim d'instàncies a retornar ? Això combinat amb la pregunta de wikibase permetria treure una quantitat raonable i avisar de que és incomplerta, perquè tal com ho tenim, o surt tot o no surt res.
Per cert, com que "d'un gran mal en surt un gran bé", ens ha servit per afinar i millorar algunes males pràctiques.
