XML est souvent mal employé, c'est sur. Maintenant, développant une appli qui utilise précisément du XML gzippé pour ses fichiers (lesquels comprennent le plus souvent bien plus de 1000 items), je t'assure que ça scale très bien, nos temps de chargements sont tout a fait acceptables, quand on a voulu les accelerer ça n'est pas du coté de XML qu'on a regardé, mais du traitement après. Parser du XML c'est pas spécialement lent.
Dans le cas des bookmarks de konq, je présume qu'ils passent par DOM plutôt que SAX pour les lire (ça serait logique vu qu'ils sont présentés comme un arbre), donc il est évident que tu vas manger un peu coté perfs. Ceci dit, pour seulement 1000 enregistrements, je ne crois pas que cela soit très sensible, le ralentissement viens plutôt de l'infrastructure de KDE qui maintient les bookmarks de manière centralisée.
Ce que tu ne veux pas comprendre c'est que le gain de vitesse dont tu parles, dans 99% des cas d'applis end-user, on s'en fout complètement, ça fait une différence négligeable. Par contre, avoir un format de fichier robuste et qui se lit facilement, ÇA ça fait une énorme différence pour le développeur, et pour l'utilisateur au final parce qu'il perdra moins souvent ses data.
Je viens de faire un test tout con : grep sur un fichier de 600 000 lignes (six cent mille, plus d'un demi-million). Le fichier fait 33Mb au total. grep bouffe ça en 0.04 secondes, sur mon P4 2.4GHz, une machine vieille de 2 ans. 4 centièmes de secondes pour scanner une regexp sur 33Mb. Tu es sur d'avoir si souvent besoin d'une DB ?
Donc pour ce qui est d'aller reflechir et des commentaires méprisants, pour l'instant c'est plutôt toi qui croit avoir compris un truc ("SQLLite c'est bon, mangez-en") et qui pense que les autres sont des truffes de ne pas l'avoir compris, alors que dès que tu as 2 sous d'expérience, le truc que tu apprends (souvent douloureusement), c'est "les DBs c'est sympa mais faut pas en abuser".
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par Guillaume Laurent . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 8.
Dans le cas des bookmarks de konq, je présume qu'ils passent par DOM plutôt que SAX pour les lire (ça serait logique vu qu'ils sont présentés comme un arbre), donc il est évident que tu vas manger un peu coté perfs. Ceci dit, pour seulement 1000 enregistrements, je ne crois pas que cela soit très sensible, le ralentissement viens plutôt de l'infrastructure de KDE qui maintient les bookmarks de manière centralisée.
Ce que tu ne veux pas comprendre c'est que le gain de vitesse dont tu parles, dans 99% des cas d'applis end-user, on s'en fout complètement, ça fait une différence négligeable. Par contre, avoir un format de fichier robuste et qui se lit facilement, ÇA ça fait une énorme différence pour le développeur, et pour l'utilisateur au final parce qu'il perdra moins souvent ses data.
Je viens de faire un test tout con : grep sur un fichier de 600 000 lignes (six cent mille, plus d'un demi-million). Le fichier fait 33Mb au total. grep bouffe ça en 0.04 secondes, sur mon P4 2.4GHz, une machine vieille de 2 ans. 4 centièmes de secondes pour scanner une regexp sur 33Mb. Tu es sur d'avoir si souvent besoin d'une DB ?
Donc pour ce qui est d'aller reflechir et des commentaires méprisants, pour l'instant c'est plutôt toi qui croit avoir compris un truc ("SQLLite c'est bon, mangez-en") et qui pense que les autres sont des truffes de ne pas l'avoir compris, alors que dès que tu as 2 sous d'expérience, le truc que tu apprends (souvent douloureusement), c'est "les DBs c'est sympa mais faut pas en abuser".