• [^] # Re: Mais donc les performances ?

    Posté par (site web personnel) . En réponse à la dépêche Retour d'expérience sur sql.js. Évalué à 5.

    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).