Voir la source de Discussion modèle:Date rapide

{{À faire}}

== Balise {{balise|time}} ==

Ne faudrait-il pas rajouter un peu de code afin de supporter la balise HTML5 {{balise|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 {{m|date}} évite normalement.

[[Spécial:Contributions/149.154.209.45|149.154.209.45]] ([[Discussion utilisateur:149.154.209.45|discuter]]) 27 septembre 2015 à 00:12 (CEST)

== Retrait des liens internes non thématiques ? ==

Utilisé dans environ {{formatnum:1140}}&nbsp;articles, ce modèle a le même rôle que {{m|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 [[Wikipédia:Sondage/Liens internes sur le modèle Date|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 [https://wstat.fr/template/info/Date_rapide wstat], la syntaxe semble toujours de la forme <code><nowiki>{{Date rapide|JJ|mois|AAAA}}</nowiki></code> ou <code><nowiki>{{Date rapide|JJ|mois|thématique}}</nowiki></code>, 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 <small>(en comparaison)</small> « 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 : {{n-|Od1n|Golmote|Escargot bleu}}. — [[Utilisateur:Ideawipik|Ideawipik]] ([[Discussion utilisateur:Ideawipik|discuter]]) 7 août 2023 à 16:57 (CEST)

:@[[Utilisateur:Ideawipik|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 {{m-|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 {{m-|date rapide}} et {{m-|date}}, c'est que le premier n'insère aucune balise sémantique <code><nowiki><time></nowiki></code>.
:Je ne suis pas certain qu'il soit pertinent d'utiliser [[Module:Date]] dans {{m-|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 {{m-|date}} pourrait être extrapolé à {{m-|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 <code>liens</code> qui peut valoir <code>oui</code> pour restaurer le comportement initial, comme cela a été fait sur {{m|date}}. Tout ça doit pouvoir se faire en wikicode sans trop impacter la perf, non ? --[[Utilisateur:Golmote|Golmote]] ([[Discussion utilisateur:Golmote|discuter]]) 7 août 2023 à 19:08 (CEST)
::@[[Utilisateur:Ideawipik|Ideawipik]] Oh, je crois que je viens de comprendre différemment une partie de ton message : quand tu dis {{cd|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 {{m-|Date rapide|JJ|mois|AAAA}} en {{m-|Date|JJ|mois|AAAA}} ? (A la première lecture, je pensais que tu voulais appeler {{m-|Date}} depuis {{m-|Date rapide}}...) Pourquoi pas, mais quel bénéfice à le remplacer ? --[[Utilisateur:Golmote|Golmote]] ([[Discussion utilisateur:Golmote|discuter]]) 7 août 2023 à 19:19 (CEST)
:::Bonjour [[User:Golmote|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 <code>liens</code>.— [[Utilisateur:Ideawipik|Ideawipik]] ([[Discussion utilisateur:Ideawipik|discuter]]) 7 août 2023 à 19:44 (CEST)
::::Bonjour à vous deux. Ce modèle remonte effectivement à une époque où le modèle {{m|Date}} n'était pas codé en Lua, et posait des problèmes sur certaines pages, en particulier à cause de la limitation à 500&nbsp;<code>#ifexist</code>. 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 {{m|Date rapide}} reste donc encore pertinent sur certaines pages.
::::Un point important est que l'utilisation de Lua dans {{m|Date rapide}} supprimerait complètement son intérêt, puisqu'il se retrouverait avec un coût d'exécution similaire à {{m|Date}}.
::::Pour ce qui est du comportement à faire adopter à ce modèle, suite au retrait des liens dans {{m|Date}}, je pense qu'il faut évidemment calquer son fonctionnement sur {{m|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 {{m|Date rapide}} dans les articles, bien entendu lorsqu'il est justifié c'est-à-dire utilisé des centaines de fois sur la page.
::::<span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 7 août 2023 à 22:28 (CEST)
:::::Merci [[User:Od1n|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 ? <syntaxhighlight lang="wikitext">{{#if: {{Oui non|{{{liens|}}}|défaut=}}{{{4|}}}
  | comportement avec liens partout (le code en vigueur jusqu'à présent)
  | comportement sans lien (code simplifié)
}}</syntaxhighlight> où la présence du <code>défaut</code> vide a son importance pour reproduire le comportement de Date, i.e. pas de liens si la valeur passée dans <code>liens</code> est non vide mais ni oui, ni non, au sens de {{m|Oui non}}. Ou, plus direct, avec un test <code>#if</code> sur <syntaxhighlight lang="wikitext" inline>{{#switch: {{lc: {{{liens|}}} }} |oui|o|yes|y|true|1 = 1 |#default = }}{{{4|}}}</syntaxhighlight> où la syntaxe de valeur par défaut est facultative mais facilite la compréhension. <small>Digression : notons la légère différence entre le modèle {{m|Oui non}} et le [[Module:Yesno]] pour les valeurs des chaînes de caractères "true" et "false".</small> Merci. — [[Utilisateur:Ideawipik|Ideawipik]] ([[Discussion utilisateur: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 : {{nombre|500|utilisations}} de {{m|Date}} (sans les liens, donc un peu plus performant qu'avant) prennent {{unité|500|ms}}, ce n'est pas grand chose mais ça fait encore {{unité|1|ms}} pour ''chaque'' utilisation ; et avec les liens, on est à {{unité|650|ms}}. Quant à {{m|Date rapide}}, {{nombre|500|utilisations}} prennent {{unité|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 {{m|Oui non}} je pense qu'on passerait de {{unité|200|ms}} à {{unité|300|ms}}, donc une différence encore moins intéressante…
::::::<span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 8 août 2023 à 00:32 (CEST)
:::::::En me basant sur le [https://wstat.fr/template/index.php?title=Date_rapide&query=info&ns=all rapport wstat.fr] actuel, je viens de générer un [[Utilisateur:Od1n/Utilisations Date rapide|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 à {{m|Date}} ne ferait perdre que quelques centaines de ms.
:::::::Concernant {{m|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…
:::::::<span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 9 août 2023 à 00:42 (CEST)
::::::::En remplaçant {{m|Date rapide}} par {{m|Date}} sur la plus grosse page, [[Liste des épisodes de Détective Conan]] et ses 1149 inclusions, on passe de {{unité|2.143|secondes}} à {{unité|3.231|secondes}}. Un autre problème cependant, le markup supplémentaire augmente la taille du résultat, qui passe de {{unité|1811081|octets}} à {{unité|2066568|octets}}, c'est-à-dire très très près de la limite de {{unité|2097152|octets}}… <span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 9 août 2023 à 00:52 (CEST)
{{retour indentation|::::::::}}
: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 {{m|Date}} sur les pages ayant, par exemple, moins de 20 inclusions ?
:Wikipédiennement, [[Utilisateur:Epok|Epok__]] <small>([[Discussion utilisateur:Epok|✉]])</small>, le 20 janvier 2024 à 09:40 (CET)
::J'ai fait tourner mon [[Utilisatrice:Bottine|bot]] pour remplacer {{m|date rapide}} par {{m|date}} dans les pages avec moins de {{nobr|20 occurrences}}. Le modèle {{m|date rapide}} était avant utilisé dans {{nobr|1166 pages}}, maintenant il l'est dans {{nobr|312 pages}}.
::Je viens aussi de refaire quelques essais, l'ordre de grandeur reste de {{unité|1|ms}} par appel de {{m|date}}, mais {{m|date rapide}} semble être devenu un peu plus performant, là il est environ cinq fois plus rapide que {{m|date}}. Peut-être qu'il y a eu des optimisations dans le parseur de MediaWiki. Ainsi, pour {{nobr|100 dates}}, ça prend {{unité|100|ms}} avec {{m|date}} et {{unité|20|ms}} avec {{m|date rapide}} ; la différence n'est pas insignifiante.
::<span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 8 février 2024 à 10:28 (CET)
:::Super, merci {{u-|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" ?
:::[[Utilisateur:Epok|Epok__]] <small>([[Discussion utilisateur:Epok|✉]])</small>, 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 : {{citation|L'utilisation de <nowiki>{{date rapide}}</nowiki> n'est justifiée qu'en cas de centaines, voire milliers d'inclusions. Dans la plupart des cas, préférez <nowiki>{{date}}</nowiki>, qui est plus court et offre davantage de possibilités.}}
::::Concernant les performances de {{m|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 {{unité|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 {{m|date}} : autres modèles/modules plus coûteux, limite "post-expand include size", navigateur qui rame pour tout afficher…
::::<span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 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 ?
:::::[[Utilisateur:Epok|Epok__]] <small>([[Discussion utilisateur:Epok|✉]])</small>, le 9 février 2024 à 21:26 (CET)
::::::Depuis la création de {{m|date rapide}}, la situation a bien évolué :
::::::* passage de {{m|date}} en Lua, améliorant ses performances et mieux encore, permettant de l'utiliser plus de {{nobr|500 fois}} par page ;
::::::* récemment retrait des liens dans {{m|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 {{m|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 {{3e|point}}, on pouvait être tenté de fortement privilégier {{m|date}}, mais à la suite de ce {{3e|point}}, ça pourrait être dommage de perdre quelques centaines de {{abrd|ms|millisecondes}} sur les grosses pages.
::::::Cependant, lorsqu'une page est grosse, "foutu pour foutu" on n'est plus à quelques centaines de {{abrd|ms|millisecondes}} 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 {{unité|2|Mo}} et les {{unité|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 {{m|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)
::::::<span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 10 février 2024 à 05:08 (CET)
:::::::Je viens de faire une nouvelle passe, traitant les pages avec moins de {{nobr|50 occurrences}}. À ce niveau de nombre d'occurrences, je pense qu'un gain de quelques dizaines de {{abrd|ms|millisecondes}} ne vaut pas la simplicité de la syntaxe de {{m|date}} (ainsi que le markup sémantique qu'il ajoute). On est passé de 323 pages utilisant le modèle, à 125 maintenant. <span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 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 ! [[Utilisateur:Epok|Epok__]] <small>([[Discussion utilisateur:Epok|✉]])</small>, 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 {{m|date}} ou {{m|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 <code>mw.clone()</code> 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. <span class="romain">[[Utilisateur:Od1n|od†n]]</span>&nbsp;↗<sup>[[Discussion utilisateur:Od1n|blah]]</sup> 24 mai 2024 à 10:28 (CEST)