Je dis juste « lol » pour ça (et je m'explique ensuite) :
Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing. Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
Créer une requête SQL et la parser c'est surement moins d'1% du temps d'exécution de la requête. Relativement c'est minuscule et ça permet par contre beaucoup de choses impossibles, complexes ou lentes par rapport à des formats binaires classiques. À côté de ça, SQLite est un SGBDR très rapide pour tout ce qui est lecture sans locks (surement 99% des accès pour un package manager, et 100% des choses pour lesquelles on lui demande d'être rapide). Utiliser une BDD permet également d'indexer facilement sur les différents champs pour optimiser les opérations de recherche courantes (à un certain coût lors des modifications, mais on s'en fiche pas mal par rapport au nombre de lectures).
Je ferais remarquer également sur l'argument de la vitesse que pacman, qui est considéré comme un des packages managers les plus rapides (mais bon, il gère moins de choses que les autres aussi) utilise le filesystem pour gérer la database des paquets. Un dossier par dépot dans /var/lib/pacman/sync, et un dossier par paquet du dépot qui contient un fichier « desc » et un fichier « depends ». C'est tout sauf optimisé pour le problème, c'est indexé n'importe comment et de manière non contrôlée par le filesystem, et c'est pourtant très rapide. Utilise une DB ne pourra être que mieux sur ce point (d'ailleurs, ça fait partie des choses prévues pour pacman, mais pour lesquelles personne n'a encore proposé de patch).
Bref, c'est bien beau de balancer des faits sans rien derrière. Faut juste éviter de se planter complètement comme tu viens de le faire.
[^] # Re: Gestionnaire de paquets de Chakra
Posté par Pierre Bourdon . En réponse au journal Chakra se sépare d'Arch. Évalué à 8.
Ils utilisent une base de donnée SQLite, qu'ils interrogent en SQL. Ça va les tuer du côté des performances, car le moindre accès à la BDD passe par la création d'une requête SQL, puis son parsing. Ils seront obligés de faire de grosses requêtes (mais pas souvent), puis du traitement du côté C++ pour rattraper le coup.
Créer une requête SQL et la parser c'est surement moins d'1% du temps d'exécution de la requête. Relativement c'est minuscule et ça permet par contre beaucoup de choses impossibles, complexes ou lentes par rapport à des formats binaires classiques. À côté de ça, SQLite est un SGBDR très rapide pour tout ce qui est lecture sans locks (surement 99% des accès pour un package manager, et 100% des choses pour lesquelles on lui demande d'être rapide). Utiliser une BDD permet également d'indexer facilement sur les différents champs pour optimiser les opérations de recherche courantes (à un certain coût lors des modifications, mais on s'en fiche pas mal par rapport au nombre de lectures).
Je ferais remarquer également sur l'argument de la vitesse que pacman, qui est considéré comme un des packages managers les plus rapides (mais bon, il gère moins de choses que les autres aussi) utilise le filesystem pour gérer la database des paquets. Un dossier par dépot dans /var/lib/pacman/sync, et un dossier par paquet du dépot qui contient un fichier « desc » et un fichier « depends ». C'est tout sauf optimisé pour le problème, c'est indexé n'importe comment et de manière non contrôlée par le filesystem, et c'est pourtant très rapide. Utilise une DB ne pourra être que mieux sur ce point (d'ailleurs, ça fait partie des choses prévues pour pacman, mais pour lesquelles personne n'a encore proposé de patch).
Bref, c'est bien beau de balancer des faits sans rien derrière. Faut juste éviter de se planter complètement comme tu viens de le faire.