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...
[^] # Re: Mais donc les performances ?
Posté par lovasoa (site web personnel) . En réponse à la dépêche Retour d'expérience sur sql.js. Évalué à 1.
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...