J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?
J'ai besoin d'une base de donnée pour un programme C.
MySQL, PostgreSQL etc... Il y en a plein...T'as pas déjà posé la question ?
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Jean-Marc
"James Kanze" a écrit dans le message de news:
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en général l'optimisation la plus importante), la vitesse d'exécution, l'utilisation mémoire (qui joue aussi sur la vitesse -- plus tu tiens en mémoire, plus la récherche sera rapide) ; typiquement, en fait, la première démarche d'optimisation d'un tel programme, c'est de s'organiser pour maintenir le plus possible en mémoire.
Certes, mais attention à la robustesse dans ce cas. Comme tu le faisais remarquer, quelles contraintes de robustesse doivent être tenues? Parce que c'est le problème avec le "tout en mémoire".
En fait, je pense que ça dépend de ce que veut faire faire le prof: - Apprendre à bosser en mémoire (tableaux,listes chainées,etc) - Apprendre à utilisers les fonctions d'accès aux fichiers
On aura dans ces 2 cas des programmes très différents.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"James Kanze" <james.kanze@free.fr> a écrit dans le message de
news:m2654prfmi.fsf@thomas.gabi-soft.fr...
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
général l'optimisation la plus importante), la vitesse d'exécution,
l'utilisation mémoire (qui joue aussi sur la vitesse -- plus tu tiens en
mémoire, plus la récherche sera rapide) ; typiquement, en fait, la
première démarche d'optimisation d'un tel programme, c'est de
s'organiser pour maintenir le plus possible en mémoire.
Certes, mais attention à la robustesse dans ce cas. Comme tu le faisais
remarquer, quelles contraintes de robustesse doivent être tenues? Parce
que c'est le problème avec le "tout en mémoire".
En fait, je pense que ça dépend de ce que veut faire faire le prof:
- Apprendre à bosser en mémoire (tableaux,listes chainées,etc)
- Apprendre à utilisers les fonctions d'accès aux fichiers
On aura dans ces 2 cas des programmes très différents.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en général l'optimisation la plus importante), la vitesse d'exécution, l'utilisation mémoire (qui joue aussi sur la vitesse -- plus tu tiens en mémoire, plus la récherche sera rapide) ; typiquement, en fait, la première démarche d'optimisation d'un tel programme, c'est de s'organiser pour maintenir le plus possible en mémoire.
Certes, mais attention à la robustesse dans ce cas. Comme tu le faisais remarquer, quelles contraintes de robustesse doivent être tenues? Parce que c'est le problème avec le "tout en mémoire".
En fait, je pense que ça dépend de ce que veut faire faire le prof: - Apprendre à bosser en mémoire (tableaux,listes chainées,etc) - Apprendre à utilisers les fonctions d'accès aux fichiers
On aura dans ces 2 cas des programmes très différents.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
James Kanze
"Jean-Marc" writes:
|> "James Kanze" a écrit dans le message de |> news:
|> > Optimiser quoi dans tout ça ? Le temps de programmation (c'est en |> > général l'optimisation la plus importante), la vitesse |> > d'exécution, l'utilisation mémoire (qui joue aussi sur la vitesse |> > -- plus tu tiens en mémoire, plus la récherche sera rapide) ; |> > typiquement, en fait, la première démarche d'optimisation d'un tel |> > programme, c'est de s'organiser pour maintenir le plus possible en |> > mémoire.
|> Certes, mais attention à la robustesse dans ce cas. Comme tu le |> faisais remarquer, quelles contraintes de robustesse doivent être |> tenues? Parce que c'est le problème avec le "tout en mémoire".
Justement. On peut faire le tout en mémoire, mais à condition de s'assurer que la copie sur disque reste conforme. Où qu'il y a au moins un fichier de journalisation pour pouvoir le rendre conforme, le cas échéant.
C'est peut-être aussi utile à signaler qu'on ne peut pas faire réelement robuste en C, parce qu'il n'existe rien pour s'assurer la synchronisation des disques.
|> En fait, je pense que ça dépend de ce que veut faire faire le prof: |> - Apprendre à bosser en mémoire (tableaux,listes chainées,etc) |> - Apprendre à utilisers les fonctions d'accès aux fichiers
|> On aura dans ces 2 cas des programmes très différents.
Tout à fait. (Mais peut-être le but, caché, c'est de voir qui est assez intelligent pour ne pas réinventer la roue, et chercher des solutions existantes:-).)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
"Jean-Marc" <nospamjean_marc_n2@yahoo.fr> writes:
|> "James Kanze" <james.kanze@free.fr> a écrit dans le message de
|> news:m2654prfmi.fsf@thomas.gabi-soft.fr...
|> > Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
|> > général l'optimisation la plus importante), la vitesse
|> > d'exécution, l'utilisation mémoire (qui joue aussi sur la vitesse
|> > -- plus tu tiens en mémoire, plus la récherche sera rapide) ;
|> > typiquement, en fait, la première démarche d'optimisation d'un tel
|> > programme, c'est de s'organiser pour maintenir le plus possible en
|> > mémoire.
|> Certes, mais attention à la robustesse dans ce cas. Comme tu le
|> faisais remarquer, quelles contraintes de robustesse doivent être
|> tenues? Parce que c'est le problème avec le "tout en mémoire".
Justement. On peut faire le tout en mémoire, mais à condition de
s'assurer que la copie sur disque reste conforme. Où qu'il y a au moins
un fichier de journalisation pour pouvoir le rendre conforme, le cas
échéant.
C'est peut-être aussi utile à signaler qu'on ne peut pas faire réelement
robuste en C, parce qu'il n'existe rien pour s'assurer la
synchronisation des disques.
|> En fait, je pense que ça dépend de ce que veut faire faire le prof:
|> - Apprendre à bosser en mémoire (tableaux,listes chainées,etc)
|> - Apprendre à utilisers les fonctions d'accès aux fichiers
|> On aura dans ces 2 cas des programmes très différents.
Tout à fait. (Mais peut-être le but, caché, c'est de voir qui est assez
intelligent pour ne pas réinventer la roue, et chercher des solutions
existantes:-).)
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> "James Kanze" a écrit dans le message de |> news:
|> > Optimiser quoi dans tout ça ? Le temps de programmation (c'est en |> > général l'optimisation la plus importante), la vitesse |> > d'exécution, l'utilisation mémoire (qui joue aussi sur la vitesse |> > -- plus tu tiens en mémoire, plus la récherche sera rapide) ; |> > typiquement, en fait, la première démarche d'optimisation d'un tel |> > programme, c'est de s'organiser pour maintenir le plus possible en |> > mémoire.
|> Certes, mais attention à la robustesse dans ce cas. Comme tu le |> faisais remarquer, quelles contraintes de robustesse doivent être |> tenues? Parce que c'est le problème avec le "tout en mémoire".
Justement. On peut faire le tout en mémoire, mais à condition de s'assurer que la copie sur disque reste conforme. Où qu'il y a au moins un fichier de journalisation pour pouvoir le rendre conforme, le cas échéant.
C'est peut-être aussi utile à signaler qu'on ne peut pas faire réelement robuste en C, parce qu'il n'existe rien pour s'assurer la synchronisation des disques.
|> En fait, je pense que ça dépend de ce que veut faire faire le prof: |> - Apprendre à bosser en mémoire (tableaux,listes chainées,etc) |> - Apprendre à utilisers les fonctions d'accès aux fichiers
|> On aura dans ces 2 cas des programmes très différents.
Tout à fait. (Mais peut-être le but, caché, c'est de voir qui est assez intelligent pour ne pas réinventer la roue, et chercher des solutions existantes:-).)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Pascal
Quel est le but du projet ? C-à-d est-ce que la base de données est accessoire, ou est-ce que le but est que tu programmes toi-même une petite base de données ? Dans le premier cas, l'utilisation d'une
Le but est d'implémenter un agenda répartie (client et server avec communication rpc). Donc la base de données est accessoire. Le tout est de justifier ce qu'on a choisit.
Un premier choix de taille : est-ce qu'on peut maintenir toutes les données en mémoire ou non ? (Avec des machines modernes, la limite pourrait bien être à plus d'une million d'enregistrements.) Et quel sont les contraints de robustité : que se passe-t-il par exemple si ton programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?
Ba j'ai choisi un serveur à donnée rémanente, ce qui me semble le plus efficace en terme de robustesse. D'ou l'utilisation de fichier.
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
Le pb avec un fichier par contact : c'est le nombre d'E/S par fichier, le gaspillage de mémoire (pour 5 lignes de fichier, on va perdre de la mémoire pour rien). C'est ce pb que je veux optimiser. Mais le pb d'un seul fichier, c'est comment faire pour retrouver rapidement un contact? Avec fgets, je récup ligne par ligne. C'est trop lent!
Quel est le but du projet ? C-à-d est-ce que la base de données est
accessoire, ou est-ce que le but est que tu programmes toi-même une
petite base de données ? Dans le premier cas, l'utilisation d'une
Le but est d'implémenter un agenda répartie (client et server avec
communication rpc). Donc la base de données est accessoire. Le tout est
de justifier ce qu'on a choisit.
Un premier choix de taille : est-ce qu'on peut maintenir toutes les
données en mémoire ou non ? (Avec des machines modernes, la limite
pourrait bien être à plus d'une million d'enregistrements.) Et quel sont
les contraints de robustité : que se passe-t-il par exemple si ton
programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?
Ba j'ai choisi un serveur à donnée rémanente, ce qui me semble le plus
efficace en terme de robustesse. D'ou l'utilisation de fichier.
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
Le pb avec un fichier par contact : c'est le nombre d'E/S par fichier,
le gaspillage de mémoire (pour 5 lignes de fichier, on va perdre de la
mémoire pour rien). C'est ce pb que je veux optimiser. Mais le pb d'un
seul fichier, c'est comment faire pour retrouver rapidement un contact?
Avec fgets, je récup ligne par ligne. C'est trop lent!
Quel est le but du projet ? C-à-d est-ce que la base de données est accessoire, ou est-ce que le but est que tu programmes toi-même une petite base de données ? Dans le premier cas, l'utilisation d'une
Le but est d'implémenter un agenda répartie (client et server avec communication rpc). Donc la base de données est accessoire. Le tout est de justifier ce qu'on a choisit.
Un premier choix de taille : est-ce qu'on peut maintenir toutes les données en mémoire ou non ? (Avec des machines modernes, la limite pourrait bien être à plus d'une million d'enregistrements.) Et quel sont les contraints de robustité : que se passe-t-il par exemple si ton programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?
Ba j'ai choisi un serveur à donnée rémanente, ce qui me semble le plus efficace en terme de robustesse. D'ou l'utilisation de fichier.
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
Le pb avec un fichier par contact : c'est le nombre d'E/S par fichier, le gaspillage de mémoire (pour 5 lignes de fichier, on va perdre de la mémoire pour rien). C'est ce pb que je veux optimiser. Mais le pb d'un seul fichier, c'est comment faire pour retrouver rapidement un contact? Avec fgets, je récup ligne par ligne. C'est trop lent!
Thierry Boudet
On10-31, Pascal wrote:
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez vous de cette idée?
Attention, quand on dépasse un certain nombre de fichiers dans le même répertoire, les performances baissent, et ça peut devenir inutilisable: "ls -l *.contact" ne marche plus.
fu2 fr.comp.developpement
-- _/°< coin
On10-31, Pascal <pascal@spam.org> wrote:
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?
Attention, quand on dépasse un certain nombre de fichiers dans le
même répertoire, les performances baissent, et ça peut devenir
inutilisable: "ls -l *.contact" ne marche plus.
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez vous de cette idée?
Attention, quand on dépasse un certain nombre de fichiers dans le même répertoire, les performances baissent, et ça peut devenir inutilisable: "ls -l *.contact" ne marche plus.
fu2 fr.comp.developpement
-- _/°< coin
bruno modulix
NB : hs ici, donc xpost et fu2 fcdev
Quel est le but du projet ? C-à-d est-ce que la base de données est accessoire, ou est-ce que le but est que tu programmes toi-même une petite base de données ? Dans le premier cas, l'utilisation d'une
Le but est d'implémenter un agenda répartie (client et server avec communication rpc). Donc la base de données est accessoire. Le tout est de justifier ce qu'on a choisit.
Un premier choix de taille : est-ce qu'on peut maintenir toutes les données en mémoire ou non ? (Avec des machines modernes, la limite pourrait bien être à plus d'une million d'enregistrements.) Et quel sont les contraints de robustité : que se passe-t-il par exemple si ton programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?
Ba j'ai choisi un serveur à donnée rémanente, ce qui me semble le plus efficace en terme de robustesse. D'ou l'utilisation de fichier.
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
Le pb avec un fichier par contact : c'est le nombre d'E/S par fichier, le gaspillage de mémoire (pour 5 lignes de fichier, on va perdre de la mémoire pour rien). C'est ce pb que je veux optimiser. Mais le pb d'un seul fichier, c'est comment faire pour retrouver rapidement un contact? Avec fgets, je récup ligne par ligne. C'est trop lent!
Avec un index, généralement sous forme d'arbre ou de table de hachage - et bien sûr persistant en mémoire secondaire. Utiliser si possible pour les données un fichier avec des enregistrements à taille fixe, pour accéder directement à l'enregistrement recherché.
Le tout est une recette bien connue, ça s'appelle un fichier séquentiel indexé, ou isam : http://www.webopedia.com/TERM/I/ISAM.html
Mais si la base de donnée n'est pas le but de l'exercice, utiliser plutôt berkeley db (cf lien dans un autre post), qui fait déjà tout ça très bien.
Dernier point : le but de l'exercice est le rpc, donc occupe-toi du rpc et ne perd pas ton temps avec des problèmes de performance.
Eventuellement, défini une API simple encapsulant les problèmes d'accès fichier, de sorte à pouvoir changer de mode de stockage par la suite sans retoucher la logique applicative.
Bruno
NB : hs ici, donc xpost et fu2 fcdev
Quel est le but du projet ? C-à-d est-ce que la base de données est
accessoire, ou est-ce que le but est que tu programmes toi-même une
petite base de données ? Dans le premier cas, l'utilisation d'une
Le but est d'implémenter un agenda répartie (client et server avec
communication rpc). Donc la base de données est accessoire. Le tout est
de justifier ce qu'on a choisit.
Un premier choix de taille : est-ce qu'on peut maintenir toutes les
données en mémoire ou non ? (Avec des machines modernes, la limite
pourrait bien être à plus d'une million d'enregistrements.) Et quel sont
les contraints de robustité : que se passe-t-il par exemple si ton
programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?
Ba j'ai choisi un serveur à donnée rémanente, ce qui me semble le plus
efficace en terme de robustesse. D'ou l'utilisation de fichier.
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
Le pb avec un fichier par contact : c'est le nombre d'E/S par fichier,
le gaspillage de mémoire (pour 5 lignes de fichier, on va perdre de la
mémoire pour rien). C'est ce pb que je veux optimiser. Mais le pb d'un
seul fichier, c'est comment faire pour retrouver rapidement un contact?
Avec fgets, je récup ligne par ligne. C'est trop lent!
Avec un index, généralement sous forme d'arbre ou de table de hachage -
et bien sûr persistant en mémoire secondaire. Utiliser si possible pour
les données un fichier avec des enregistrements à taille fixe, pour
accéder directement à l'enregistrement recherché.
Le tout est une recette bien connue, ça s'appelle un fichier séquentiel
indexé, ou isam :
http://www.webopedia.com/TERM/I/ISAM.html
Mais si la base de donnée n'est pas le but de l'exercice, utiliser
plutôt berkeley db (cf lien dans un autre post), qui fait déjà tout ça
très bien.
Dernier point : le but de l'exercice est le rpc, donc occupe-toi du rpc
et ne perd pas ton temps avec des problèmes de performance.
Eventuellement, défini une API simple encapsulant les problèmes d'accès
fichier, de sorte à pouvoir changer de mode de stockage par la suite
sans retoucher la logique applicative.
Quel est le but du projet ? C-à-d est-ce que la base de données est accessoire, ou est-ce que le but est que tu programmes toi-même une petite base de données ? Dans le premier cas, l'utilisation d'une
Le but est d'implémenter un agenda répartie (client et server avec communication rpc). Donc la base de données est accessoire. Le tout est de justifier ce qu'on a choisit.
Un premier choix de taille : est-ce qu'on peut maintenir toutes les données en mémoire ou non ? (Avec des machines modernes, la limite pourrait bien être à plus d'une million d'enregistrements.) Et quel sont les contraints de robustité : que se passe-t-il par exemple si ton programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?
Ba j'ai choisi un serveur à donnée rémanente, ce qui me semble le plus efficace en terme de robustesse. D'ou l'utilisation de fichier.
Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
Le pb avec un fichier par contact : c'est le nombre d'E/S par fichier, le gaspillage de mémoire (pour 5 lignes de fichier, on va perdre de la mémoire pour rien). C'est ce pb que je veux optimiser. Mais le pb d'un seul fichier, c'est comment faire pour retrouver rapidement un contact? Avec fgets, je récup ligne par ligne. C'est trop lent!
Avec un index, généralement sous forme d'arbre ou de table de hachage - et bien sûr persistant en mémoire secondaire. Utiliser si possible pour les données un fichier avec des enregistrements à taille fixe, pour accéder directement à l'enregistrement recherché.
Le tout est une recette bien connue, ça s'appelle un fichier séquentiel indexé, ou isam : http://www.webopedia.com/TERM/I/ISAM.html
Mais si la base de donnée n'est pas le but de l'exercice, utiliser plutôt berkeley db (cf lien dans un autre post), qui fait déjà tout ça très bien.
Dernier point : le but de l'exercice est le rpc, donc occupe-toi du rpc et ne perd pas ton temps avec des problèmes de performance.
Eventuellement, défini une API simple encapsulant les problèmes d'accès fichier, de sorte à pouvoir changer de mode de stockage par la suite sans retoucher la logique applicative.
Bruno
bruno modulix
Bonjour,
J'ai besoin d'une base de donnée pour un programme C. Est il possible d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai choisi cette solution. Ma base de donnée va contenir des contacts. Pour des raisons de perf, je cherche à lire le plus rapidement possible
Annuaire + lecture rapide = Annuaire LDAP. Voire du côté de openLdap (licence libre).
Bonjour,
J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible
Annuaire + lecture rapide = Annuaire LDAP. Voire du côté de openLdap
(licence libre).
J'ai besoin d'une base de donnée pour un programme C. Est il possible d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai choisi cette solution. Ma base de donnée va contenir des contacts. Pour des raisons de perf, je cherche à lire le plus rapidement possible
Annuaire + lecture rapide = Annuaire LDAP. Voire du côté de openLdap (licence libre).
