Discussion modèle:Date rapide

	Tâches à accomplir pour Modèle:Date rapide	modifier • suivre • rafraîchir • aide
	Créer les pages de dates manquantes (celles nommées [[Mois année]], par exemple Avril 2002), pour faire progressivement disparaître les liens rouges sur les mois. Procéder année par année, à partir de 1987 puis en remontant dans le passé. Les mois manquants peuvent être vus dans la partie Chronologie mensuelle du tableau figurant sur les pages des années. plus maintenant, suite à une modification sur le modèle {{Années}} ; la solution restante est de consulter les catégories (par exemple Catégorie:1988)

Balise <time>

Ne faudrait-il pas rajouter un peu de code afin de supporter la balise HTML5 <time>, qui certes augmenterait un peu la complexité du modèle, sans pour autant effectuer toute la gestion lourde des liens rouges que le modèle {{date}} évite normalement.

149.154.209.45 (discuter) 27 septembre 2015 à 00:12 (CEST)

Retrait des liens internes non thématiques ?

Utilisé dans environ 1 140 articles, ce modèle a le même rôle que {{Date}}, à la différence qu'il ne vérifie pas l'existence d'une page avant de générer les liens (pour éviter que la page dans laquelle il est inséré ne sollicite trop de fonctions d'analyse coûteuses). Il me semble que le retrait des liens internes par défaut, appliqué dans l'autre modèle, le concerne aussi. Dans de "petites" pages (comme Dr. Luigi), la sollicitation de ce modèle n'a pas lieu d'être. D'après wstat, la syntaxe semble toujours de la forme {{Date rapide|JJ|mois|AAAA}} ou {{Date rapide|JJ|mois|thématique}}, avec parfois un JJ vide. Dans la première situation, l'appel du modèle pourra être remplacé par celui d'un simple « Date ». Sauf erreur, le module général sous-jacent ne vérifie pas inutilement l'existence des pages cibles, avant de décider s'il insérera ou non des liens internes, donc il ne devrait pas y avoir de problème majeur de performances, même si le fonctionnement est moins léger que le simplissime (en comparaison) « Date rapide ».

Notons que contrairement au modèle « Date », « Date rapide » n'insère de lien "thématique" que sur l'année et n'accepte que la syntaxe "longue" à trois paramètres pour la date. On pourrait lui retirer tous ses liens internes, excepté sur l'année quand il y a un quatrième paramètre. Autre possibilité : laisser tous les liens (même non thématiques) s'il y a un paramètre 4, et les retirer sinon.

Information au créateur du modèle et aux techniciens qui ont appliqué le consensus du sondage :  Od1n, Golmote et Escargot bleu. — Ideawipik (discuter) 7 août 2023 à 16:57 (CEST)

@Ideawipik Bonjour ! Je présume que ce modèle date d'une époque où le Module:Date n'existait pas encore et où le modèle {{date}} était réputé assez coûteux ? (On trouve dans la documentation du Module:Date quelques comparaisons avant/après entre l'ancien modèle date et le nouveau.) Une autre différence entre {{date rapide}} et {{date}}, c'est que le premier n'insère aucune balise sémantique <time>.

Je ne suis pas certain qu'il soit pertinent d'utiliser Module:Date dans {{date rapide}}. Si on veut que ce modèle soit particulièrement performant, il vaut mieux ne pas exécuter de Lua non ? Si je lis correctement Module:Date/Data et sa documentation, on dirait que le module vérifie encore l'existence des pages « mois d'une année spécifique » pour les années comprises entre 1762 et 1772 et les années après 2021 (selon moi cette dernière valeur pourrait être modifiée à 2023) lorsqu'aucune thématique n'est présente. Et lorsqu'une thématique est présente, bah ça dépend des données de ce sous-module.

Je pense que le consensus exprimé par le sondage du modèle {{date}} pourrait être extrapolé à {{date rapide}}, oui. Ta description du comportement sans liens par défaut me semble bien (lien uniquement sur l'année quand il y a une thématique). Mais il faudrait peut-être ajouter un paramètre liens qui peut valoir oui pour restaurer le comportement initial, comme cela a été fait sur {{date}}. Tout ça doit pouvoir se faire en wikicode sans trop impacter la perf, non ? --Golmote (discuter) 7 août 2023 à 19:08 (CEST)

@Ideawipik Oh, je crois que je viens de comprendre différemment une partie de ton message : quand tu dis Dans la première situation, l'appel du modèle pourra être remplacé par celui d'un simple « Date », tu veux dire qu'il serait possible de faire passer un bot pour changer toutes les occurrences de {{Date rapide|JJ|mois|AAAA}} en {{Date|JJ|mois|AAAA}} ? (A la première lecture, je pensais que tu voulais appeler {{Date}} depuis {{Date rapide}}...) Pourquoi pas, mais quel bénéfice à le remplacer ? --Golmote (discuter) 7 août 2023 à 19:19 (CEST)

Bonjour Golmote. Oui, je parlais de ce type de remplacement dans les articles, sans faire passer expressément un bot pour cela, mais remplacement cosmétique possible au fil de l'eau. Il vaut mieux éviter d'utiliser des modèles alternatifs quand le modèle général sied, afin d'éviter des propagations par copier-coller.

Pour le modèle « Date rapide », je pensais effectivement le laisser en wikicode, sauf avis contraires en faveur d'améliorations (par exemple, pour ajouter des balises « time », voir section supra, ou pour autoriser la syntaxe synthétique à un paramètre). Pas opposé à l'ajout d'un paramètre liens.— Ideawipik (discuter) 7 août 2023 à 19:44 (CEST)

Bonjour à vous deux. Ce modèle remonte effectivement à une époque où le modèle {{Date}} n'était pas codé en Lua, et posait des problèmes sur certaines pages, en particulier à cause de la limitation à 500 #ifexist. Le passage à Lua, en utilisant une table de données, a permis d'éliminer une grande partie de ces tests "page existe", et donc de réduire l'écart de performances entre ces deux modèles.

Néanmoins, il reste l'overhead de l'invocation Lua, qui est très significatif si le modèle est appelé des centaines de fois. Le modèle {{Date rapide}} reste donc encore pertinent sur certaines pages.

Un point important est que l'utilisation de Lua dans {{Date rapide}} supprimerait complètement son intérêt, puisqu'il se retrouverait avec un coût d'exécution similaire à {{Date}}.

Pour ce qui est du comportement à faire adopter à ce modèle, suite au retrait des liens dans {{Date}}, je pense qu'il faut évidemment calquer son fonctionnement sur {{Date}} : pas de liens s'il n'y a pas de thématique, et liens s'il y a une thématique. Je suis contre le truc hybride consistant à avoir une partie de la date sans liens et une partie avec lien.

Enfin, je pense qu'il faut laisser le modèle {{Date rapide}} dans les articles, bien entendu lorsqu'il est justifié c'est-à-dire utilisé des centaines de fois sur la page.

od†n ↗^blah 7 août 2023 à 22:28 (CEST)

Merci Od1n. Le surplus lié au module Lua est-il chargé à chaque appel du modèle « Date » ou une fois pour toutes ? Quant au code de « Date rapide », une évolution comme la suivante est-elle acceptable, niveau performances ?

{{#if: {{Oui non|{{{liens|}}}|défaut=}}{{{4|}}}
  | comportement avec liens partout (le code en vigueur jusqu'à présent)
  | comportement sans lien (code simplifié)
}}

où la présence du défaut vide a son importance pour reproduire le comportement de Date, i.e. pas de liens si la valeur passée dans liens est non vide mais ni oui, ni non, au sens de {{Oui non}}. Ou, plus direct, avec un test #if sur {{#switch: {{lc: {{{liens|}}} }} |oui|o|yes|y|true|1 = 1 |#default = }}{{{4|}}} où la syntaxe de valeur par défaut est facultative mais facilite la compréhension. Digression : notons la légère différence entre le modèle {{Oui non}} et le Module:Yesno pour les valeurs des chaînes de caractères "true" et "false". Merci. — Ideawipik (discuter) 7 août 2023 à 23:49 (CEST)

L'overhead de Lua est pour chaque invocation. C'est léger, mais ça s'additionne, donc s'il y a des milliers d'invocations…

Je viens de faire quelques benchmarks : 500 utilisations de {{Date}} (sans les liens, donc un peu plus performant qu'avant) prennent 500 ms, ce n'est pas grand chose mais ça fait encore 1 ms pour chaque utilisation ; et avec les liens, on est à 650 ms. Quant à {{Date rapide}}, 500 utilisations prennent 200 ms, la différence existe encore, mais ne change pas grand chose, au mieux sur une énorme page on va gagner genre une demi-seconde. Et en ajoutant le {{Oui non}} je pense qu'on passerait de 200 ms à 300 ms, donc une différence encore moins intéressante…

od†n ↗^blah 8 août 2023 à 00:32 (CEST)

En me basant sur le rapport wstat.fr actuel, je viens de générer un rapport sur les utilisations de ce modèle. Après observation des rapports "NewPP", j'ai l'impression que même sur les plus grosses pages, le passage à {{Date}} ne ferait perdre que quelques centaines de ms.

Concernant {{Date}}, j'ai l'impression que la plus grosse partie du coût d'exécution est l'overhead de l'invocation Lua, et que le code Lua à proprement parler est vraiment très rapide. Du coup, il n'y aurait pas grand chose à gagner en optimisant le module. Néanmoins, je pense que le code du module gagnerait à être étudié de fond en comble, notamment afin de le mettre au propre, le simplifier et le rendre plus maintenable…

od†n ↗^blah 9 août 2023 à 00:42 (CEST)

En remplaçant {{Date rapide}} par {{Date}} sur la plus grosse page, Liste des épisodes de Détective Conan et ses 1149 inclusions, on passe de 2,143 secondes à 3,231 secondes. Un autre problème cependant, le markup supplémentaire augmente la taille du résultat, qui passe de 1 811 081 octets à 2 066 568 octets, c'est-à-dire très très près de la limite de 2 097 152 octets… od†n ↗^blah 9 août 2023 à 00:52 (CEST)

┌────────────────┘

Hello,

J'arrive après la bataille, mais je voulais ajouter que ce modèle est beaucoup utilisé dans des contextes où il n'est pas justifié. Beaucoup de pages avec moins de 10 inclusions, voire avec une seule inclusion du modèle...

J'en ai corrigé un certain nombre au fil du temps, mais vu le nombre d’occurrences, est-ce que ce ne serait pas nécessaire de faire passer un bot pour le remplacer par {{Date}} sur les pages ayant, par exemple, moins de 20 inclusions ?

Wikipédiennement, Epok__ (✉), le 20 janvier 2024 à 09:40 (CET)

J'ai fait tourner mon bot pour remplacer {{date rapide}} par {{date}} dans les pages avec moins de 20 occurrences. Le modèle {{date rapide}} était avant utilisé dans 1166 pages, maintenant il l'est dans 312 pages.

Je viens aussi de refaire quelques essais, l'ordre de grandeur reste de 1 ms par appel de {{date}}, mais {{date rapide}} semble être devenu un peu plus performant, là il est environ cinq fois plus rapide que {{date}}. Peut-être qu'il y a eu des optimisations dans le parseur de MediaWiki. Ainsi, pour 100 dates, ça prend 100 ms avec {{date}} et 20 ms avec {{date rapide}} ; la différence n'est pas insignifiante.

od†n ↗^blah 8 février 2024 à 10:28 (CET)

Super, merci Od1n !

Faudrait-il mentionner ces indications de performances dans la doc, et éventuellement un ordre de grandeur pour le seuil à partir duquel on peut utiliser ce modèle avec une amélioration qui "vaut le coup" ?

Epok__ (✉), le 8 février 2024 à 21:36 (CET)

C'est déjà dans la doc, et je trouve la formulation déjà plutôt correcte : « L'utilisation de {{date rapide}} n'est justifiée qu'en cas de centaines, voire milliers d'inclusions. Dans la plupart des cas, préférez {{date}}, qui est plus court et offre davantage de possibilités. »

Concernant les performances de {{date}}, j'ai l'impression qu'on ne doit pas être loin du mieux possible, et que le gros du coût est le chargement de Lua. Il faut donc accepter cet ordre de grandeur de 1 ms par utilisation. De toute façon, lorsqu'une page est de très grande taille, d'autres problèmes devraient se présenter avant celui du coût des {{date}} : autres modèles/modules plus coûteux, limite "post-expand include size", navigateur qui rame pour tout afficher…

od†n ↗^blah 9 février 2024 à 08:03 (CET)

Oui, c'est simplement que je pensais que tes nouvelles stats mettaient à mal cette remarque en réduisant le nombre d'utilisations nécessaires pour obtenir une optimisation significative. Si ces valeurs de la doc sont toujours d'actualité, alors il faut peut-être aller au-delà des remplacements sur les pages ayant plus d'une 20aine d'utilisations ? A-t-on un moyen rapide d'estimer le nombre d'utilisations par page ? Le nombre de pages avec moins de 100 (ou 1000 ?) inclusions, notamment ?

Epok__ (✉), le 9 février 2024 à 21:26 (CET)

Depuis la création de {{date rapide}}, la situation a bien évolué :

• passage de {{date}} en Lua, améliorant ses performances et mieux encore, permettant de l'utiliser plus de 500 fois par page ;
• récemment retrait des liens dans {{date}}, améliorant encore la situation, mais seulement lorsque pas de paramètre de thématique… donc considérer que la situation n'a pas changé sur ce point ;
• et encore plus récemment, performances du parseur MediaWiki qui semblent s'être améliorées, améliorant ainsi les performances de {{date rapide}} (juste après observation empirique, rien d'autre pour étayer cela).

Donc en tout cas, les choses vont mieux qu'avant. Avant l'arrivée du 3^e point, on pouvait être tenté de fortement privilégier {{date}}, mais à la suite de ce 3^e point, ça pourrait être dommage de perdre quelques centaines de ms sur les grosses pages.

Cependant, lorsqu'une page est grosse, "foutu pour foutu" on n'est plus à quelques centaines de ms près… Ce qui compte surtout, c'est que la page puisse être générée complètement, sans atteindre de limites, en l'occurrence notamment le "post-expand include size" de 2 Mo et les 10 s de temps d'exécution Lua. Pour le "post-expand include size" j'ai indiqué plus haut un exemple où la limite est atteinte (la vraie solution serait de scinder l'article avec une page pour chaque saison), et pour le temps d'exécution Lua je pense qu'on a encore de la marge.

À propos j'ai fait un test rapide avec {{Date}}, ça serait à confirmer, mais j'ai l'impression qu'en gros on a 80 % du coût pour l'overhead de chargement Lua et 20 % pour l'exécution du code Lua à proprement parler.

(pour ce qui est d'effectuer l'inventaire du nombre d'utilisations par page, ça peut évidemment se faire, mais je n'ai pas de "solution rapide" sous la main)

od†n ↗^blah 10 février 2024 à 05:08 (CET)

Je viens de faire une nouvelle passe, traitant les pages avec moins de 50 occurrences. À ce niveau de nombre d'occurrences, je pense qu'un gain de quelques dizaines de ms ne vaut pas la simplicité de la syntaxe de {{date}} (ainsi que le markup sémantique qu'il ajoute). On est passé de 323 pages utilisant le modèle, à 125 maintenant. od†n ↗^blah 10 février 2024 à 07:04 (CET)

Ok, merci pour cette réponse détaillée, et pour les remplacements supplémentaires. Je pense qu'on y voit plus clair maintenant ! Epok__ (✉), le 10 février 2024 à 14:00 (CET)

Pour information, des optimisations sur le temps de chargement des modules Lua ont été effectuées, voir phab:T357199. L'intérêt est surtout pour les modules utilisés de nombreuses fois dans les pages, tels que {{date}} ou {{unité}}. Si on considère un "overhead d'invocation" représentant 80 % du temps total d'exécution du module (bien entendu, cette proportion doit varier selon les modules, mais c'est juste pour avoir un ordre de grandeur) et que les optimisations effectuées améliorent de 15 % le mw.clone() qui est la function la plus coûteuse de cet overhead (mais l'overhead n'est pas constitué que de cette fonction, il y aurait encore d'autres choses à compter), ça donne une amélioration de 12 % du temps d'exécution de chaque appel de module, en réalité certainement moins, vu que là j'ai fait une évaluation incomplète et optimiste. Aller, disons 10 % au mieux. Ce n'est pas révolutionnaire, mais c'est un petit gain qui est quand même bon à prendre. od†n ↗^blah 24 mai 2024 à 10:28 (CEST)