| |
Posté le 21 novembre 2005 - 17:56 |
Dans un programme j'ai une liste d'entiers tous differents que j'enrichie au cours de mon algorythme. A chaque boucle je verifie que l'entier que je traite existe ou pas dans la liste et si il n'existe pas je le stocke eventuellement dans la liste selon d'autres criteres. Les entiers ne peuvent malheureusement pas traites dans un ordre croissant ou decroissant (c'est aleatoire).
Quelle est la meilleure methode pour stocker cette liste d'entier afin de rendre les operation de stockage et de recherche la plus rapide possible
- un tableau (sachant que dans TableauCherche je pourrais utiliser que tcLinéaire a moins de le trier avant la recherche et utiliser tcDichotomique )
- une source de donnees dans laquelle je stockerai cet entier comme cle unique et utiliserai hlitrecherchepremier
Le nombre d'entiers peut etre egal a 100000, le traitement hors recherche prend 6heures... d'ou la question
Merci de votre aide |
| |
| |
| | | |
|
| | |
| |
Posté le 22 novembre 2005 - 08:48 |
salut
je savais pas qu'on pouvait indexer une source de données
le tableau c'est pas mal, mieux que les zones mémoires.
on peut faire aussi une table invisible mais c'est quasiment pareil |
| |
| |
| | | |
|
| | |
| |
Posté le 22 novembre 2005 - 09:56 |
je pense que dans ton traitement ce ne sont pas les fonctions tableau... qui
vont bcp te ralentir,
je doute qu'un tableaucherche sur 100000 entiers soit long !
tiens nous au courant de test résutats !
bon courage !
eric l
"olivier rethore" <orethore@rochester.rr.com> a écrit dans le message de
news: 4381f60c$1@news.pcsoft.fr...
Dans un programme j'ai une liste d'entiers tous differents que j'enrichie
au cours de mon algorythme. A chaque boucle je verifie que l'entier que je
traite existe ou pas dans la liste et si il n'existe pas je le stocke
eventuellement dans la liste selon d'autres criteres. Les entiers ne
peuvent malheureusement pas traites dans un ordre croissant ou decroissant
(c'est aleatoire).
Quelle est la meilleure methode pour stocker cette liste d'entier afin de
rendre les operation de stockage et de recherche la plus rapide possible
- un tableau (sachant que dans TableauCherche je pourrais utiliser que
tcLinéaire a moins de le trier avant la recherche et utiliser
tcDichotomique )
- une source de donnees dans laquelle je stockerai cet entier comme cle
unique et utiliserai hlitrecherchepremier
Le nombre d'entiers peut etre egal a 100000, le traitement hors recherche
prend 6heures... d'ou la question
Merci de votre aide
|
| |
| |
| | | |
|
| | |
| |
Posté le 22 novembre 2005 - 10:37 |
Ca depend:
Est-ce que tu peux connaitre au moment de la création du tableau combien d'éléments il devra contenir? Ca me parait être un point très important.
Méfiez-vous tout de même des tableaux dynamiques...
Et si on veut de la recherche dichotomique, faudra souvent trier le tableau en cas d'ajout intempestif!
Le problème qu'on a avec ce genre de question c'est qu'on ne sait pas exactement comment windev gère les tableaux dynamiques.
Si on ajoute plusieurs fois de suite des éléments dans un tableau dynamique, est-ce que la capacité du tableau augmente juste d'une unité à la fois? Ou est-ce que ça augmente avec un pas de 5, 10 ou 20?
Parce que si ca augmente une unité à la fois, faut chaque fois réallouer tout le tableau...
Le problème c'est qu'on a pas ce genre de transparence dans l'aide. |
| |
| |
| | | |
|
| | |
| |
Posté le 22 novembre 2005 - 11:12 |
Salut
Utilise le profiler et tu auras ta réponse.
--
Ciao
Pat Biker
http://aaa.windev.free.fr/
On Mon, 21 Nov 2005 16:56:58 +0100, "olivier rethore"
<orethore@rochester.rr.com> wrote:
Dans un programme j'ai une liste d'entiers tous differents que j'enrichie au cours de mon algorythme. A chaque boucle je verifie que l'entier que je traite existe ou pas dans la liste et si il n'existe pas je le stocke eventuellement dans la liste selon d'autres criteres. Les entiers ne peuvent malheureusement pas traites dans un ordre croissant ou decroissant (c'est aleatoire).
Quelle est la meilleure methode pour stocker cette liste d'entier afin de rendre les operation de stockage et de recherche la plus rapide possible
- un tableau (sachant que dans TableauCherche je pourrais utiliser que tcLinéaire a moins de le trier avant la recherche et utiliser tcDichotomique )
- une source de donnees dans laquelle je stockerai cet entier comme cle unique et utiliserai hlitrecherchepremier
Le nombre d'entiers peut etre egal a 100000, le traitement hors recherche prend 6heures... d'ou la question
Merci de votre aide
|
| |
| |
| | | |
|
| | |
| |
Posté le 22 novembre 2005 - 12:51 |
exact...!
cependant dans l'api il existe une fonction pour réallouer un buffer :
utilisation de la place
libre en ram derrière la première allocation (avec déplacement en ram du
buffer
si nécessaire)...
http://msdn.microsoft.com/library/default.asp…
cette fonction peut retourner un erreur mais elle marche quasi tout le temps
ca permet
de gagner du temps
je ne sais pas comment WD gère ses allocations bien sûr...
mais effectivement si les éléments peuvent alloués par 5, 10 ou n c'est
encore mieux
pour ce genre d'utilisation 
eric l.
"Stef" <guest@newsgroup.fr> a écrit dans le message de news:
4382e074$1@news.pcsoft.fr...
Ca depend:
Est-ce que tu peux connaitre au moment de la création du tableau combien
d'éléments il devra contenir? Ca me parait être un point très important.
Méfiez-vous tout de même des tableaux dynamiques...
Et si on veut de la recherche dichotomique, faudra souvent trier le
tableau en cas d'ajout intempestif!
Le problème qu'on a avec ce genre de question c'est qu'on ne sait pas
exactement comment windev gère les tableaux dynamiques.
Si on ajoute plusieurs fois de suite des éléments dans un tableau
dynamique, est-ce que la capacité du tableau augmente juste d'une unité à
la fois? Ou est-ce que ça augmente avec un pas de 5, 10 ou 20?
Parce que si ca augmente une unité à la fois, faut chaque fois réallouer
tout le tableau...
Le problème c'est qu'on a pas ce genre de transparence dans l'aide.
|
| |
| |
| | | |
|
| | |
| |
Posté le 22 novembre 2005 - 18:09 |
Merci a tous pour vos avis. Je vais profiter de cette fin de semaine pour tester differents scenarios et vous donnerai un resume la semaine prochaine. |
| |
| |
| | | |
|
| | |
| |
Posté le 23 novembre 2005 - 14:58 |
Avec toutes vos recommendations voici les conclusions des tests:
j'ai bien sur utilise l'analyseur de performance et le gestionnaire de tache de window
1 - il semble que WD gere correctement les tableaux dynamiques:
* les recherches sont tres rapides (moyenne 47microsecondes pour 200000 entiers
dans le tableau)
* l'ajout est rapide: 11 microsecondes
* l'allocation de memoire semble se faire correctement: il n'y a pas d'augmentation
sensible de la memoire durant le process de chargement du tableau.
2 - l'acces a une source fichier en lecture est rapide mais moins performant que les tableaux:
Pour une source de 11000 enregistrements de 50 octets
* HFiltre 19 microsecondes
* HlitPremier 132 microsecondes mais HLitSuivant 27 microsecondes
3 - WD ne sait pas gerer correctement les ajouts dans une source fichier. Le probleme de
reallocation n'est pas traite et la memoire utilisee ne cesse d'augmenter jusqu'a
un plantage memoire.
En clair ne jamais utiliser les sources pour creer des enregistrements mais seulement
les consulter.
Autre chose que j'ai decouvert sur les filtres appliques sur les sources fichiers.
Le Hlitpremier suivant:
condition=rubrique+"="+valeur
cledeparcours=HFiltre(source,condition)
Hlitpremier(source,cledeparcours)
est 50 a 100 fois plus long que celui-ci:
hfiltre(source,rubrique,valeur,valeur)
Hlitpremier(source,rubrique)
Il semble que l'optimisation de soit pas active dans les sources fichier.
A+ |
| |
| |
| | | |
|
| | |