En effet, j'ai été regarder dans le dossier /var/lib/pacman, et ça fait peur. Je n'y étais jamais allé, merci de me faire découvrir pourquoi la moitié des inodes de ma partition sont déjà pris, et pourquoi un pacman -Sy prend tant de temps.
Sinon, le SQL peut être très rapide, j'ai eu l'occasion de beaucoup de tester. Il y a un an, j'avais fait un gestionnaire de paquet (j'aime développer des gestionnaires de paquets :-° ) qui utilisant une base SQLite, en passant par QtSql.
Alors oui, il y a des requêtes un peu lourdes, mais assez efficaces. Mais il y a aussi le problème des multiples requêtes.
Par exemple, tu dois résoudre les dépendances d'un paquet. Pour cela, deux solution :
* Une grosse requête qui te dump la table packages_deps, et tu traite le tout en C++. Grosse consommation de RAM
* Plein de petites requêtes quand t'en a besoin
Oui, complexité O(nombre de dépendances), très rapide. Du C pur*, pas d'accès à une BDD, c'est indexé, etc.
En fait, une base de donnée binaire fait-maison est la solution la plus rapide qu'il soit, car c'est adapté au problème. Maintenant, obtenir cette rapidité est difficile (perso : 2 mois de réflexion au moins).
Le résultat : à la sortie de Setup 0.1-alpha2, je ferai une vidéo montrant l'instantanéité de tous les traitements de Setup, malgré le fait qu'il utilise un solveur à graphe orienté : http://logram-project.org/news-2-66-1-un-nouveau-solveur-de-(...) . (Solveur d'ailleurs pas encore optimisé, qui compare des chaînes de caractère. Je dois encore faire en sortie qu'il compare des index de chaînes, sachant que toutes les chaines de caractères de la BDD sont indexées).
*Sauf l'ajout à une QList, mais il est possible de ne pas utiliser cette fonction et donc de ne pas avoir ce confort qu'on paie côté perfs.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par steckdenis . En réponse au journal Chakra se sépare d'Arch. Évalué à 1.
En effet, j'ai été regarder dans le dossier /var/lib/pacman, et ça fait peur. Je n'y étais jamais allé, merci de me faire découvrir pourquoi la moitié des inodes de ma partition sont déjà pris, et pourquoi un pacman -Sy prend tant de temps.
Sinon, le SQL peut être très rapide, j'ai eu l'occasion de beaucoup de tester. Il y a un an, j'avais fait un gestionnaire de paquet (j'aime développer des gestionnaires de paquets :-° ) qui utilisant une base SQLite, en passant par QtSql.
Alors oui, il y a des requêtes un peu lourdes, mais assez efficaces. Mais il y a aussi le problème des multiples requêtes.
Par exemple, tu dois résoudre les dépendances d'un paquet. Pour cela, deux solution :
* Une grosse requête qui te dump la table packages_deps, et tu traite le tout en C++. Grosse consommation de RAM
* Plein de petites requêtes quand t'en a besoin
Les deux solutions sont lentes. Je t'invite à regarder comment on peut gérer ça élégamment avec des fichiers mappés : http://gitorious.org/logram/setup/blobs/master/libpackage/da(...) .
Oui, complexité O(nombre de dépendances), très rapide. Du C pur*, pas d'accès à une BDD, c'est indexé, etc.
En fait, une base de donnée binaire fait-maison est la solution la plus rapide qu'il soit, car c'est adapté au problème. Maintenant, obtenir cette rapidité est difficile (perso : 2 mois de réflexion au moins).
Le résultat : à la sortie de Setup 0.1-alpha2, je ferai une vidéo montrant l'instantanéité de tous les traitements de Setup, malgré le fait qu'il utilise un solveur à graphe orienté : http://logram-project.org/news-2-66-1-un-nouveau-solveur-de-(...) . (Solveur d'ailleurs pas encore optimisé, qui compare des chaînes de caractère. Je dois encore faire en sortie qu'il compare des index de chaînes, sachant que toutes les chaines de caractères de la BDD sont indexées).
*Sauf l'ajout à une QList, mais il est possible de ne pas utiliser cette fonction et donc de ne pas avoir ce confort qu'on paie côté perfs.