lovasoa a écrit 164 commentaires

Il y a paperless qui fait exactement la même chose, en python aussi, et qui est "trending" en ce moment sur github. Est-ce qu'il y a eu une influence quelconque de l'un sur l'autre? Est-ce qu'il serait envisageable de rendre les deux compatibles ? (synchroniser paperwork avec un serveur paperless)…

Une autre limite, plus importante encore, je pense, de cette analogie, est que tout le monde ou presque peut comprendre une recette de cuisine, ou au moins comprendre la liste des aliments qui la composent. Alors que le code source d'un logiciel n'a, pour l'immense majorité de ses utilisateurs, aucune signification.

Il me semble évident que détecter un charset invalide accélère le programme, et ne le ralentit pas. En effet, quand une incohérence entre un charset et le texte courant est trouvée, on peut arrêter la collecte de statistiques pour ce charset, et gagner du temps pour la poursuite de la lecture. C'est ce qui semble être fait dans uchardet pour WINDOWS-1252, mais visiblement pas pour WINDOWS-1255.

Je ne sais pas si c'est le seul problème, mais cette ligne me semble fautive. Je pense que les cinq dernières valeurs devraient être 255,255,128, 96,255, du moins si l'on en croit le commentaire au dessus de la liste de valeur:

/****************************************************************
255: Control characters that usually does not exist in any text
254: Carriage/Return
253: symbol (punctuation) that does not belong to word
252: 0 - 9
*****************************************************************/

Uchardet le fait.

C'est faux, et je l'ai montré dans un commentaire précédent.
Mais puisque tu dis qu'il est censé le faire, je viens d'ouvrir un rapport de bug.

Pour reprendre l'exemple précédent: f3 ec ed fb e9 va donner СЛМШИ en KOI8-R. Ce ne sont que des lettres qui existent en russe. Pourtant, le résultat ne veut rien dire. On est bien obligé de travailler avec des données précises sur chacune des langues que l'on veut détecter.

Par contre, on peut, et je pense qu'il faut, détecter les points de codes qui ne sont pas valides dans un encodage donné. Et ça, uchardet ne le fait visiblement pas.

On pourrait imaginer, en plus, d'attribuer des points négatifs quand un caractère qui n'appartient pas à la langue est détecté.

D'accord, je corrige ça.

Je viens de vérifier sur l'article que j'ai mis en lien, que j'avais lu trop vite. WINDOWS-1252 n'est pas seulement très proche, il est totalement compatible avec ISO-8859-1, la seule différence se trouvant dans des caractères qui sont "non-imprimables" en ISO-8859-1. Donc n'importe quel texte ISO-8859-1 sera détecté par uchardet comme du WINDOWS-1252, et sera effectivement décodé correctement en tant que WINDOWS-1252.

C'est vrai que ça améliorerait l'empreinte mémoire. Pour l'instant, chez moi, avec 3 dictionnaires, le programme utilise au maximum 100Mo de mémoire.

Pour ce qui est du temps de recherche, je ne pense pas que ce serait mieux… La recherche dans un set python est en O(1), et est en pratique rapide.

À propos de l'algorithme: il est tout bête. On construit des HashMap (des set pythons, ici) contenant tous les mots de chaque langue que l'on veut détecter. En suite, pour chaque codec, on cherche la langue dans laquelle il donne le plus de mots d'un HashMap. On retient ce nombre de mots. À la fin, on cherche le codec qui a donné le plus de mots existants.

Bien sûr, cela implique d'avoir des dictionnaires qui comprennent toutes les formes, déclinées et conjuguées, de tous les mots. Pour certaines langues, ce n'est pas possible…

Effectivement, utiliser un autre langage de programmation devrait permettre d'obtenir de meilleures performances.

On pourrait aussi envisager de ne pas tester les couples langue-encodage qui n'ont pas de sens. Ça devrait permettre de gagner encore du temps.

Chez moi, /usr/share/dict contient aussi d'autres fichiers, qui ne sont pas des dictionnaires. Mais effectivement, il y a mieux que de lister en dur les noms des fichiers :/

Merci de toutes ces précisions et conseils. Je suis très content d'avoir le mainteneur d'uchardet parmi mes lecteurs!

C'est vrai qu'uchardet ne supporte pas ISO-8859-1, mais tu devrais peut-être préciser aux lecteurs qu'il supporte WINDOWS-1252, qui est très très proche, et qui permet donc souvent de décoder ses fichiers texte en français sans problèmes.

Je me réjouis grandement de savoir que bientôt gedit ouvrira naturellement les fichiers textes qui ne sont pas en UTF-8. Merci pour ton travail, il me sera utile!

Effectivement, mon approche est plus complexe algorithmiquement, mais c'est le prix à payer pour des résultats plus fiables. Je pense que mettre uniquement les mots les plus courants ne permettrait pas de surpasser la fiabilité d'uchardet, qui est déjà plutôt bonne. Je voulais surtout avoir un truc dont je suis sûr qu'il marche à tous les coups, et ça ne me dérange pas de perdre systématiquement 2 secondes avant de démarrer un film avec des sous-titres. Mais j'ai conscience que cette approche n'est pas utilisable au sein d'une librairie qui aurait autant d'utilisations différentes qu'uchardet.

Et pour donner un exemple d'un cas où uchardet peut être induit en erreur à cause de sa méthode statistique:

La suite d'octets e0 f0 f4 fb, est détectée par uchardet comme étant du WINDOWS-1255. Or ce n'est même pas une chaîne valide dans ce codec. Simplement, les trois premiers octets correspondent à des lettres fréquentes en hébreux. Je laisse au lecteur le plaisir de découvrir la chaîne de caractères qui se cache vraiment derrière ces octets…

Je me rends compte que j'aurais peut-être dû préciser pourquoi une connaissance de la fréquence des lettres ou d'un dictionnaire est nécessaire.

La plupart des encodages de caractères (à l'exception notable d'UTF8) sauront décoder n'importe quelle suite d'octets que vous lui donnez. Donc on ne peut pas se contenter de vérifier si le codec ne retourne pas d'erreur en décodant le texte, il faut aussi vérifier que ce qu'il retourne est cohérent avec une langue.

Par exemple, la chaîne d'octets f3 ec ed fb e9 peut-être décodée par les codecs WINDOWS-1251 (donnant умный), ISO-8859-1 (donnant óìíûé), KOI8-R (donnant СЛМШИ), et beaucoup d'autres. Seul умный a un sens dans une langue (cela signifie intelligent en russe). Mon programme va le détecter en détectant que c'est le seul qui existe dans un dictionnaire. uchardet va le détecter en se rendant compte que les lettres у, м, н, ы, й sont plus fréquentes en russe que n'importe lesquelles des lettres des autres résultats dans n'importe quel langage.

Le cat au début de la commande est inutile!

>,[<++++[->--------<]>[>,--------------------------------]<[>[-]++++[-<++++++++>]<.<]>[-]<++++[->++++++++<]>.[-],]

Le code source n'est pas disponible pour le moment mais c'est à l'étude.

Je ne vais pas donner d'argent pour le moment mais c'est à l'étude.

Je trouve le concept très intéressant, et l'année dernière, j'avais failli participer… Et finalement non.

Parce que travailler gratuitement c'est déjà pas génial, mais bon, dans le domaine du libre, on a l'habitude. Mais payer pour travailler, désolé, ça ne va pas être possible.

Travailler pour un musée, c'est intéressant, et on se sent utile. Mais c'est quand même du travail. Et être payé -50€ pour trois jours de travail, ce n'est pas cool du tout.

En fait, le programme python que tu présentes n’est pas équivalent au javascript dont la vitesse est mesurée dans jsperf.

Dans le jsperf, la base est totalement détruite, et reconstruite, entre chaque requête, mais seul le temps pris par la requête (SELECT ou INSERT) est mesuré.

Dans ton script python, tu mesures le temps pris par l’ensemble du programme (y compris le temps pris pour démarrer l’interpréteur et parser ton script), et toutes les requêtes sont faites à la suite sur la même base. C'est particulièrement dérangeant pour les INSERT, car chaque INSERT est fait sur une base un peu plus grosse. Idem pour le test JSPerf que tu as ajouté.

De manière générale, quel que soit le langage, il vaut mieux éviter d’inventer des méthodes de test de performance si on n’a pas des notions de statistiques. JSPerf fait les choses sérieusement.

Au final, les résultats devraient être encore plus en faveur du SQLite natif de python…

petit JSperf

Tout ce que j’ai pour le moment, c’est cette petite page de jsperf qui indique les performances en lecture et en écriture. Comme je n’ai pas tellement travaillé sur le sujet (à part faire attention aux flags de compilation, et écrire du code propre), je ne l’ai pas mentionné ici.

Pour les gens pressés, spoiler du jsperf ci-dessus: sur ma machine, 2500 SELECTs par seconde, et 500 INSERT par seconde.

Idées pour le futur

Mais l’étude des performances est très intéressante, et je vais certainement travailler dessus. J'avais par exemple envie de réécrire une partie du code de l’interface en C aussi, pour qu’il soit compilé en asm.js, et plus rapide. Dans le moteur js de firefox, les changements de contexte entre du code en asm.js et du code en javascript simple sont coûteux (ou du moins l’étaient la dernière fois que je me suis renseigné dessus). Donc il peut être intéressant d’écrire en C des routines qui vont, par exemple, préparer une requête, y attacher des paramètres, l'exécuter, et récupérer les résultats.

Du côté d’emscripten

En fait, j’ai un peu travaillé sur les performances, mais de manière plus générale, directement dans emscripten. Voire cette pull request, qui a maintenant été fusionnée, et qui contient de jolis graphes de performance.

Le patch consiste à optimiser les fonctions ccall (qui permet d’appeler une fonction C compilée depuis du code javascript) et la fonction cwrap (qui retourne une fonction qui elle-même appelle la fonction C compilée). Ces deux fonctions permettent notamment de convertir les chaînes de caractères javascript en tableau de char alloués sur la pile (la pile virtuelle d’emscripten).

J'ai eu un retour d'un utilisateur qui l'utilisait avec node dans un projet avec node-webkit, pour ne pas avoir à compiler son projet pour chaque plateforme.

Kripken, l’auteur original du projet, m’a finalement ajouté aux contributeurs de sql.js sur son dépôt github, entre le moment ou j’ai écrit cette dépêche et le moment où elle a été publiée. Donc kripken/sql.js contient maintenant le même code que lovasoa/sql.js.

C'est en mémoire, mais pas read only. Tu peux exporter ta base après coup.
C'est ACID, parce que SQLite respecte les propriétés acid. C'est thread safe, pour la simple raison que le seul moyen de faire des threads en js dans le navigateur, ce sont les web workers, et qu'ils ne permettent pas de partager la mémoire.

Si la base est déjà en SQLite côté serveur, et qu'elle ne contient pas de données sensibles, ça peut valoir le coup de l'envoyer direct vers le client.

Le système de types de sqlite est tout de même un peu plus fin que juste "démerdez-vous" : http://www.sqlite.org/datatype3.html

il n'y a pas besoin de tout le code de SQLite4 (converti donc en asm.js) pour avoir au final qu'un interpreteur SQL.

Quelle partie de SQLite serait inutile? Toute la partie concernant le stockage de données serait implémentée en js avec un binding vers localStorage. Le code compilé contiendrait toute la logique de la base de données relationnelle, et ça, c'est utile. Et pour les performances, je pense qu’on a de la marge.

J’ai envie de dire: C'est vous qui voyez!

Ça peut être utile pour des applications qui traitent des bases de données de quelques milliers d’enregistrements, et qui peuvent faire des requêtes diverses sur les données. Par exemple: afficher des graphes. Cela permet de soulager le serveur, et de gagner en performances (plus besoin d’une requête réseau par requête à la BDD).

Bien sûr, le fait que la base de données doive-t-être téléchargée entièrement côté client exige qu’elle ne contienne pas de données sensibles. Le fait qu’elle soit stockée intégralement en mémoire exige qu’elle ne soit pas trop grosse.

J’ai eu quelques retours d’utilisateurs, apparemment la plupart cherchent à faire des systèmes de visualisation de données: leurs données sont déjà dans des bases SQLite, et ils veulent utiliser des bibliothèques javascript comme d3 pour les visualiser.

En fait, la base de données est stockée intégralement en mémoire. L'avantage, c'est que c'est rapide (du moins, pas trop lent).

L'inconvénient, c'est qu'on se limite à de petites bases de données.

C'est aussi pour ça que j'attends beaucoup de sqlite4. Il permettra de faire assez simplement le lien entre SQLite et les mécanismes qui permettent de stocker des données sur le disque en JavaScript, comme localStorage.