Julien Jorge a écrit 590 commentaires

C'est intéressant que tu lui trouves de la mauvaise foi, je trouve au contraire qu'il est de bonne volonté :) Il me semble bien documenté, a clairement lu le livre, et il a regardé les présentations d'Uncle Bob. Il y a beaucoup d'aller-retours au début de la discussion avec des listes de logiciels mais non pas parce qu'ils sont lents, plutôt pour s'assurer que les deux parlent du même type de logiciels. La question étant : qu'est-ce qui a besoin d'un niveau de performance à la nanoseconde, a la milliseconde, ou plus. J'aime beaucoup l'approche d'Uncle Bob aussi, qui distingue le niveau de perf en fonction de la fonctionnalité (i.e. la fenêtre de préférences de Chrome n'a pas besoin d'une réactivité folle, mais le rendu d'une page web doit être le plus efficace possible).

Je ne sens pas de fort désaccord entre les deux. L'un comme l'autre considère que la perf est importante, tant d'un point de vue algorithmique que d'implémentation, et j'en ressors plutôt que l'intention d'Uncle Bob avec Clean Code était plutôt d'améliorer la clarté des parties non impactantes sur les perfs, pour les programmeurs de tous les jours. C'est un peu dommage que ça ait été interprété comme la méthode de développement à appliquer par défaut.

Ça vaut le coup de lire aussi la discussion qu'il a eu avec Robert C. Martin, l'auteur de Clean Code, le livre qui a posé les bases de ce qu'on appelle du code "clean" : https://github.com/unclebob/cmuratori-discussion/blob/main/cleancodeqa.md

Je suppose que l'une des prochaines optimisations sera d'utiliser stringview pour éviter les copies?

Tout à fait, c'est la prochaine étape :)

Bonnes remarques, je vais ajouter les infos dans les posts. La commande perf mesure donc les cycles, sur l'ensemble du programme (y compris le chargement du fichier donc). Par contre le temps rapporté dans les tables et représenté sur les graphes correspond au temps de traitement de l'input après qu'il ait été entièrement copié dans une std::string. Il n'y a donc pas d'IO dans ces métriques.

Est-ce que les mesures faites avec perf prennent en compte uniquement le temps cpu utilisé?

Il me semble que perf compte juste des événements, sans notion de temps. Par défaut il compte les cycles CPU.

Il y a des trucs à gagner avec les streams oui. J'en parlerai dans un futur billet mais ce n'est pas encore dans le top des trucs coûteux.

(note: le lien est indiqué en français, mais il est en anglais)

C'est corrigé, merci :)

Je pense qu'il y a plusieurs raisons pour que le type « tableau associatif » du C++ soit un arbre binaire plutôt qu'une table de hachage. Entre autre choses il faut voir que cela date du début des années 90, quand il n'y avait même pas de standardisation du langage. Ensuite il faut voir qu'un arbre binaire c'est intellectuellement plaisant, et les gens qui ont produit la base du C++ à cette époque étaient plutôt intellos, du genre à considérer que tous les algos en O(n) se valent. À côté de ça une table de hachage c'est un peu bête : c'est juste un gros tableau. Et encore ça ne résout que la moitié du problème puisqu'il faut en plus lui donner une fonction de hachage rapide et avec peu de collisions. Pas simple. Dans le pire des cas on a une recherche en O(n) (toutes valeurs ont le même hash), là où l'arbre binaire est en O(log(n)) (qu'on va déguiser en O(1) en le qualifiant d'« amorti »).

C'est déjà overkill puisque cela couvre des cas non nécessaires :)

Mais cela n'est pas équivalent puisque la version originale retourne la chaîne alors que toi tu l'affiches directement :)

Idem, je suis un fervent défenseur de l'utilisation (raisonnée bien évidemment) des goto, des variables globales, et même du code à plat.

Je ne connaissais pas cet exemple, ça fait 10 minutes que je boucle entre « c'est pourri » et « c'est parfait » :D D'un côté c'est très répétitif et on a envie d'y mettre une boucle, de l'autre côté c'est tellement simple qu'on comprend l'intention au premier coup d'œil.

Lisez bien les commentaires : les vraies corrections (la partie && pourcentage <= est inutile, et il affiche la barre complète alors qu'on n'est qu'à 91%) sont arrivées bien tard dans la conversation.

Mmmh on ne va pas sortir trop tôt si on enlève le && percentage <= ? J'aurais plutôt enlevé le percentage > x &&.

Pour la barre complète à 91% je pense que ça peut s'expliquer par un ressenti utilisateur. Vaut-il mieux afficher 100% dès 91% (et l'utilisateur se demande « bah alors c'est fini ou pas ? » pendant 10%) ou rester à 0% jusqu'à avoir atteint 10% (et l'utilisateur se demande « bah alors ça commence ou quoi ? » pendant 10%) ?

Ça permet de commenter les objets mais pas les champs. Le commentaire que tu as mis au dessus de buffer sera placé ailleurs selon que l'outil utilisé pour afficher le Json réordonne les clés ou pas.

Très intéressant :) Sur le sujet des données embarquées dans le binaire, as-tu regardé les travaux de JenHeyd Meneide ? Il semblerait que l'approche xxd soit la plus chère en temps de compilation.

Concernant cette histoire de bitcoins, je crois que c'est un problème qui va au delà de la monnaie ; c'est à dire que les réactions seraient les mêmes si GIMP avait reçu directement un million d'euros de dons.

Vous pourriez décider de dépenser le million en un salaire confortable pour, au hasard, le principal développeur, qui en plus a un impact positif et énorme sur la visibilité et l'image du projet. Sans partir dans des sommes énormes, lui donner une rémunération semblable à celle d'un poste équivalent dans une entreprise classique permettrait de le sécuriser pendant quelques années. Ça ne me semblerait pas déconnant mais je suis certain que vous vous feriez lyncher :)

C'est un peu un problème dans le libre qui marche. Vu que c'est un grand projet communautaire avec plein de contributions, il y a cette règle implicite que ce que tu reçois de la communauté doit repartir dans la communauté. Ça doit repartir quasiment tel quel ; le fait d'améliorer le logiciel n'est pas considéré comme un vrai retour, puisque de toute façon il aurait été amélioré même sans les dons.

Si quelqu'un tire un bénéfice des dons, tel que pouvoir en vivre, la question se pose de pourquoi cette personne et pas une autre. Pourquoi les sous n'iraient pas directement aux fondateurs du projet ? Pourquoi ça n'irait pas à telle autre personne qui, certes, soumet moins fréquemment des patchs, mais résout des problèmes sacrément difficiles ?

Au final toute décision est mauvaise dans un sens ou un autre, alors on dépense les sous pour des à côtés : serveurs, prestas pour un logo, quelques aides pour des conférences, etc. En tout cas rien qui ne sert directement à aider les principaux contributeurs à s'investir sur le projet.

Félicitation encore et encore pour ce beau logiciel. J'ai moins l'occasion de l'utiliser qu'auparavant mais chaque dépêche me donne envie d'y retourner.

Au delà de la qualité du logiciel, j'aime aussi beaucoup l'approche de Jehan sur le développement, la communication, la communauté. Bravo et merci :)

Comme il y a beaucoup de commentaires sur la page pointée, je me permets de mettre en avant cette information issue d'un commentaire : l'index Tiobe est du caca en barre.

Peut-être devrais-je écrire aussi à ma mutuelle pour l'informer, mais ne travaillant pas dans la cybersécurité, je ne me sens pas vraiment légitime (et je n'ai peut-être pas le temps ou l'envie).

Les observations de ton journal sont tout à fait pertinentes, tu devrais leur écrire.

Et si tu as le temps d'écrire un journal comme celui-ci, je pense que tu peux trouver le temps d'écrire un mail ;)

C'est marrant, j'ai récemment adopté la demarche inverse :) Entre des contenus éparpillés ici, sur Medium, sur mon site perso, sur developpez.com, sur gamedev.net, et sur deux blogs disparus, j'en ai eu assez et j'ai décidé de tout rappatrier au même endroit. J'ai pris un nom de domaine et un serveur et je rassemble tout là-bas.

Ça ne sert pas à grand chose mais j'aime bien avoir cette historique qui me rappelle d'où je viens. Et puis si Medium fait une crise de paywall ou si un site meurt, j'aurais toujours mon contenu.

Vidéo intéressante.

On reconnait la team bujo (bullet journal) :-)

Déformation professionnelle :) À force de

• découper des tâches en sous-tâches ;
• dérouler tous les scénarios d'une exécution ;
• décrire chaque étape d'un procédé pour qu'une machine puisse l'exécuter.

J'en viens à :

• souffrir en faisant de longues phrases ;
• peiner à lier les phrases pour en faire un raisonnement logique ;
• abuser des point-virgules comme un gros snob pédant ;
• passer cinq minutes à me demander si mon interlocuteur va interpréter « je recopie ce qui est encore pertinent sur la suivante » comme « je regarde ce qui est pertinent sur la page pleine puis je recopie cela sur la page vierge » ou comme « je regarde ce qui est pertinent sur la page suivante (vierge) puis je recopie cela ». Le deuxième cas n'ayant aucun sens, le lecteur risque de buguer.

C'est pas facile pour tout le monde :)

Je prends aussi beaucoup de notes et je fonctionne beaucoup en checklists. Avant j'utilisais des feuilles de brouillon et j'avais des tonnes de boules de papier froissé dans la poubelle, autour de la poubelle, et sur mon bureau. En plus d'une pile de feuilles volantes avec des vieilles notes au cas où on sait jamais.

Depuis quelques années je suis passé à un combo cahier + stylo ; une technologie éprouvée. J'y trouve beaucoup d'avantages :

• Il n'y a plus de boules de papier froissé autour de moi.
• Ça m'aide à me focaliser. Quand une page est pleine, je fais le bilan des cases non-cochées et soit je m'y atèle, soit je recopie ce qui est encore pertinent sur la suivante. Ainsi tous les trucs qui seraient bien mais là je n'ai pas trop le temps et puis de toute façon il faudrait faire ceci avant disparaissent naturellement.
• Ça fonctionne partout, tout le temps.
• Je ne l'ai pas sur moi quand je sors du cadre du travail.
• C'est pas cher.
• J'imagine que c'est plus écologique.
• De temps en temps je le feuillette pour alimenter la satisfaction du travail accompli.

C'était bloqué pour moi aussi, puis j'ai cliqué sur le bouton « Poursuivre » qui se met sur la vidéo. Ensuite, une fois que la vidéo s'est lancée, j'ai pu faire défiler la page. Oui oui, ça n'a aucun sens.

J'ai mis LineageOS sur mon téléphone, avec l'idée initiale de me passer de Google. Pour l'instant ça ne fonctionne pas trop.

J'ai mis OsmAnd~ pour remplacer Maps et Waze, mais quand je cherche un resto j'en reviens toujours à Maps, qui me permet d'avoir des avis de personnes passées avant moi. Quand je cherche un itinéraire à vélo ou à pied, je suis souvent surpris par la complexité des trajets proposés par OsmAnd~. Les propositions de Maps me semblent plus simples pour la même durée de trajet. Pour les trajets en voiture OsmAnd~ ne prend pas en compte le trafic, du coup je lui préfère encore Waze.

Je n'ai pas encore d'alternative simple à Photos, et je suis un peu embêté à l'idée de devoir transférer des années de photos depuis le service de Google vers un autre. Surtout si l'autre ne me convient pas ou ferme dans quelque mois.

J'arrive un peu à me passer du PlayStore mais surtout parce que je n'installe pas grand chose. Les logiciels de F-Droid sont souvent décevants. On est loin de l'énergie du logiciel libre du desktop. J'ai aussi eu des soucis avec l'appli de ma banque en essayant de l'utiliser sans passer par le PlayStore.

J'ai tenté d'autres agendas mais j'ai fini par remettre celui de Google : partage facile avec les contacts, interface agréable, synchronisation facile. Par exemple les événements où je suis invités s'y affichent directement. Il me semble que ce n'était pas le cas avec les autres, y compris avec la version stock AOSP.

J'utilise encore un peu Drive. Comme pour les photos je n'ai pas trop d'alternative et je crains de me retrouver avec un service qui ne me convient pas ou qui ferme rapidement.

J'ai envisagé d'héberger un NextCloud ou un truc dans le genre pour remplacer Agenda, Drive et Photos, mais l'idée d'administrer un serveur ne m'emballe pas du tout.

Voilà, c'est pas facile. Ça aurait peut-être été plus simple si j'avais commencé sans Google il y a quelques années :)

Chez moi j'ai mis du Grade 3 qui supporte donc du 10 Gbits/s. C'est branché à un bout sur une prise Ethernet murale, et à l'autre bout sur le coffret VDI, qui est lui-même connecté à la box. Cette dernière prend le rôle du routeur.

Pour l'instant je n'ai eu aucun souci avec cette config. Je me branche au mur dans le bureau, à l'autre bout du logement, et ça dépote. Ailleurs j'ai mis un petit routeur wifi sur une prise électrique, branché en Ethernet sur la prise à côté. Ça aussi ça fonctionne très bien :)

Je devrais bientôt ajouter un switch dans le coffret pour pouvoir profiter de plus de prises.

Pour info le câble que j'ai installé est celui-ci : https://www.123elec.com/gaine-prefilee-ftp-grade-3-sat-2200mhz-d20-couronne-de-100m.html

Que penses-tu de cibler archive.org plutôt que de supprimer les liens ?

+1, ça fait tellement longtemps que l'on met la performance au second plan à grand coups de « premature optimization is the root of all evil » qu'on en vient à tout pessimiser. Même en C++ je vois encore plein de std::list là où un std::vector serait mieux, des std::map là où il faudrait utiliser std::unordered_map, des paramètres passés par valeur… Je ne parle même pas de faire des optims algorithmiques ou bas niveau ; juste d'utiliser de meilleurs outils par défaut.

C'est pas mort dillo ? La plupart des liens ne fonctionnent plus sur le site. Pas de source, pas de téléchargements… :(