Bonjour,
Je travaille seul sur Access en local. On me demande de cr=E9er des
tableaux complexes avec plusieurs colonnes : effectifs =E9l=E8ves, taux de
r=E9ussite aux examens, nombres de classes, taux de remplissage, par
commune, ann=E9e n-5; n-4, etc... ce qui fait que pour cr=E9er mon tableau
final j'utilise plusieurs requ=EAtes (s=E9lection, crois=E9e, union...).
R=E9sultat : l'ex=E9cution de la derni=E8re requ=EAte est hyper lente.
J'ai un processeur de 1,8 GHz avec une RAM de 2 Go (1 Go =E0 l'origine).
Le service informatique me dit que m=EAme si on me donne un PC plus
puissant =E7a ne changera rien. Quel est votre avis ?
Merci d'avance
Eric
ce que j'ai fait : indexation de 8 champs, compactage, création d'une nouvelle base et importation d'objets; je ne peux pas créer de clé primaire car doublons partout... Aucun changement entre les 2 bases, même délai d'exécution d'une avant- dernière requête (25 sec)
Euh ... On dirait que j'ai répondu un peu vite.
Donc, les champs sur lesquels on trie sont indexés ? Les données ont été placées dans une table unique pour tester la proposition d'Albéric ?
Bon déjà si on doit espérer une amélioration du côté logiciel , ça devrait déjà commencer à se voir. Sauf si les données comportent des redites et qu'on pourrait passer par une table qui comporte beaucoup moins d'enregistrements.
Par ailleurs, je vois : exécution 25 secondes.
ça fait largement plus de 25 secondes que nous sommes là-dessus, pas vrai ? Plus sérieusement, dans ce type de traitement, il n'est pas spécialem ent rare qu'on voie des temps de traitement de l'ordre de quarante minutes.
Vingt-cinq secondes ... Oui, il y a des chances qu'une machine plus puissante puisse apporter une accélération. Ce qui ne signifie pas nécessairement qu'on desce nde en dessous de la seconde.
A supposer qu'on réussisse à gagner vingt secondes là-dessus, que l e traitement soit lancé une fois par semaine, maintenant ce qu'il reste à préparer, c'est la démonstration pour le comptable du gain de productivité que ça apporterait pour l'entreprise de disposer de l'é tat vingt secondes plus tôt, plutôt que de le lancer pendant qu'on va boi re le café.
Et si le comptable est convaincu, il va bien trouver une machine quelque part sur laquelle faire un test.
Sur le plan logiciel, il y a un point sur lequel il est possible de travailler, c'est de proposer une barre de progression, pour que l'utilisateur perçoive bien que la machine est en train de travailler, et ait une idée du temps qu'il reste. Pour mettre ça en uvre, on r isque fort d'avoir à passer par un jeu d'enregistrements.
zzzz a écrit, le 12/07/2011 11:12 :
ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...
Aucun changement entre les 2 bases, même délai d'exécution d'une avant-
dernière requête (25 sec)
Euh ... On dirait que j'ai répondu un peu vite.
Donc, les champs sur lesquels on trie sont indexés ?
Les données ont été placées dans une table unique pour tester la
proposition d'Albéric ?
Bon déjà si on doit espérer une amélioration du côté logiciel , ça
devrait déjà commencer à se voir.
Sauf si les données comportent des redites et qu'on pourrait passer par
une table qui comporte beaucoup moins d'enregistrements.
Par ailleurs, je vois : exécution 25 secondes.
ça fait largement plus de 25 secondes que nous sommes là-dessus, pas vrai ?
Plus sérieusement, dans ce type de traitement, il n'est pas spécialem ent
rare qu'on voie des temps de traitement de l'ordre de quarante minutes.
Vingt-cinq secondes ...
Oui, il y a des chances qu'une machine plus puissante puisse apporter
une accélération. Ce qui ne signifie pas nécessairement qu'on desce nde
en dessous de la seconde.
A supposer qu'on réussisse à gagner vingt secondes là-dessus, que l e
traitement soit lancé une fois par semaine, maintenant ce qu'il reste à
préparer, c'est la démonstration pour le comptable du gain de
productivité que ça apporterait pour l'entreprise de disposer de l'é tat
vingt secondes plus tôt, plutôt que de le lancer pendant qu'on va boi re
le café.
Et si le comptable est convaincu, il va bien trouver une machine quelque
part sur laquelle faire un test.
Sur le plan logiciel, il y a un point sur lequel il est possible de
travailler, c'est de proposer une barre de progression, pour que
l'utilisateur perçoive bien que la machine est en train de travailler,
et ait une idée du temps qu'il reste. Pour mettre ça en uvre, on r isque
fort d'avoir à passer par un jeu d'enregistrements.
ce que j'ai fait : indexation de 8 champs, compactage, création d'une nouvelle base et importation d'objets; je ne peux pas créer de clé primaire car doublons partout... Aucun changement entre les 2 bases, même délai d'exécution d'une avant- dernière requête (25 sec)
Euh ... On dirait que j'ai répondu un peu vite.
Donc, les champs sur lesquels on trie sont indexés ? Les données ont été placées dans une table unique pour tester la proposition d'Albéric ?
Bon déjà si on doit espérer une amélioration du côté logiciel , ça devrait déjà commencer à se voir. Sauf si les données comportent des redites et qu'on pourrait passer par une table qui comporte beaucoup moins d'enregistrements.
Par ailleurs, je vois : exécution 25 secondes.
ça fait largement plus de 25 secondes que nous sommes là-dessus, pas vrai ? Plus sérieusement, dans ce type de traitement, il n'est pas spécialem ent rare qu'on voie des temps de traitement de l'ordre de quarante minutes.
Vingt-cinq secondes ... Oui, il y a des chances qu'une machine plus puissante puisse apporter une accélération. Ce qui ne signifie pas nécessairement qu'on desce nde en dessous de la seconde.
A supposer qu'on réussisse à gagner vingt secondes là-dessus, que l e traitement soit lancé une fois par semaine, maintenant ce qu'il reste à préparer, c'est la démonstration pour le comptable du gain de productivité que ça apporterait pour l'entreprise de disposer de l'é tat vingt secondes plus tôt, plutôt que de le lancer pendant qu'on va boi re le café.
Et si le comptable est convaincu, il va bien trouver une machine quelque part sur laquelle faire un test.
Sur le plan logiciel, il y a un point sur lequel il est possible de travailler, c'est de proposer une barre de progression, pour que l'utilisateur perçoive bien que la machine est en train de travailler, et ait une idée du temps qu'il reste. Pour mettre ça en uvre, on r isque fort d'avoir à passer par un jeu d'enregistrements.
Gloops
Gloops a écrit, le 21/07/2011 17:32 :
Sur le plan logiciel, il y a un point sur lequel il est possible de travailler, c'est de proposer une barre de progression, pour que l'utilisateur perçoive bien que la machine est en train de travailler , et ait une idée du temps qu'il reste. Pour mettre ça en uvre, on risque fort d'avoir à passer par un jeu d'enregistrements.
Il faut se méfier que l'affichage à l'écran est quelque chose qui p rend du temps, raison pour laquelle existe une instruction pour le désactive r.
Avant de s'engager dans une réflexion pour mettre en place une barre de progression, il faut savoir qu'on risque de passer de vingt-cinq secondes sans rien à l'écran à trente-cinq secondes avec une barre de progression. ça peut apporter un confort pour l'utilisateur parce qu'il sait où il en est, mais c'est une précision à ne pas oublier, car o n va à l'encontre de la question posée, au pied de la lettre.
Gloops a écrit, le 21/07/2011 17:32 :
Sur le plan logiciel, il y a un point sur lequel il est possible de
travailler, c'est de proposer une barre de progression, pour que
l'utilisateur perçoive bien que la machine est en train de travailler ,
et ait une idée du temps qu'il reste. Pour mettre ça en uvre, on risque
fort d'avoir à passer par un jeu d'enregistrements.
Il faut se méfier que l'affichage à l'écran est quelque chose qui p rend
du temps, raison pour laquelle existe une instruction pour le désactive r.
Avant de s'engager dans une réflexion pour mettre en place une barre de
progression, il faut savoir qu'on risque de passer de vingt-cinq
secondes sans rien à l'écran à trente-cinq secondes avec une barre de
progression. ça peut apporter un confort pour l'utilisateur parce qu'il
sait où il en est, mais c'est une précision à ne pas oublier, car o n va
à l'encontre de la question posée, au pied de la lettre.
Sur le plan logiciel, il y a un point sur lequel il est possible de travailler, c'est de proposer une barre de progression, pour que l'utilisateur perçoive bien que la machine est en train de travailler , et ait une idée du temps qu'il reste. Pour mettre ça en uvre, on risque fort d'avoir à passer par un jeu d'enregistrements.
Il faut se méfier que l'affichage à l'écran est quelque chose qui p rend du temps, raison pour laquelle existe une instruction pour le désactive r.
Avant de s'engager dans une réflexion pour mettre en place une barre de progression, il faut savoir qu'on risque de passer de vingt-cinq secondes sans rien à l'écran à trente-cinq secondes avec une barre de progression. ça peut apporter un confort pour l'utilisateur parce qu'il sait où il en est, mais c'est une précision à ne pas oublier, car o n va à l'encontre de la question posée, au pied de la lettre.
HD
Et puis... on a l'info du 1,8GHz pour le processeur... mais les choses peuvent pas mal changer en un celeron bas de gamme à 1,8GHz et un processeur double coeur à 1,8GHz avec cache de 2Mb... et puis le disque dur peut y faire aussi (vieux IDE ? SAS ?). Il y'a 2Go de RAM... mais pour quelle version de Windows ? Pour un Vista avec une lourde application derrière 2Go peut être insuffisant.
Mais c'est sûr qu'avant toute chose il faudrait optimiser les tables. -- @+ HD
Et puis... on a l'info du 1,8GHz pour le processeur... mais les choses
peuvent pas mal changer en un celeron bas de gamme à 1,8GHz et un processeur
double coeur à 1,8GHz avec cache de 2Mb... et puis le disque dur peut y
faire aussi (vieux IDE ? SAS ?). Il y'a 2Go de RAM... mais pour quelle
version de Windows ? Pour un Vista avec une lourde application derrière 2Go
peut être insuffisant.
Mais c'est sûr qu'avant toute chose il faudrait optimiser les tables.
--
@+
HD
Et puis... on a l'info du 1,8GHz pour le processeur... mais les choses peuvent pas mal changer en un celeron bas de gamme à 1,8GHz et un processeur double coeur à 1,8GHz avec cache de 2Mb... et puis le disque dur peut y faire aussi (vieux IDE ? SAS ?). Il y'a 2Go de RAM... mais pour quelle version de Windows ? Pour un Vista avec une lourde application derrière 2Go peut être insuffisant.
Mais c'est sûr qu'avant toute chose il faudrait optimiser les tables. -- @+ HD
Gloops
HD a écrit, le 22/07/2011 09:12 :
Et puis... on a l'info du 1,8GHz pour le processeur... mais les choses peuvent pas mal changer en un celeron bas de gamme à 1,8GHz et un pro cesseur double coeur à 1,8GHz avec cache de 2Mb... et puis le disque dur peut y faire aussi (vieux IDE ? SAS ?). Il y'a 2Go de RAM... mais pour quelle version de Windows ? Pour un Vista avec une lourde application derriè re 2Go peut être insuffisant.
C'est vrai que c'est devenu un casse-tête, maintenant, le choix d'un ordinateur ...
Mais c'est sûr qu'avant toute chose il faudrait optimiser les tables.
ça, j'avais cru comprendre (en y mettant le temps il est vrai) que c'était fait. Ou on parle de créer une clef primaire avec un numéro auto ?
HD a écrit, le 22/07/2011 09:12 :
Et puis... on a l'info du 1,8GHz pour le processeur... mais les choses
peuvent pas mal changer en un celeron bas de gamme à 1,8GHz et un pro cesseur
double coeur à 1,8GHz avec cache de 2Mb... et puis le disque dur peut y
faire aussi (vieux IDE ? SAS ?). Il y'a 2Go de RAM... mais pour quelle
version de Windows ? Pour un Vista avec une lourde application derriè re 2Go
peut être insuffisant.
C'est vrai que c'est devenu un casse-tête, maintenant, le choix d'un
ordinateur ...
Mais c'est sûr qu'avant toute chose il faudrait optimiser les tables.
ça, j'avais cru comprendre (en y mettant le temps il est vrai) que
c'était fait. Ou on parle de créer une clef primaire avec un numéro auto ?
Et puis... on a l'info du 1,8GHz pour le processeur... mais les choses peuvent pas mal changer en un celeron bas de gamme à 1,8GHz et un pro cesseur double coeur à 1,8GHz avec cache de 2Mb... et puis le disque dur peut y faire aussi (vieux IDE ? SAS ?). Il y'a 2Go de RAM... mais pour quelle version de Windows ? Pour un Vista avec une lourde application derriè re 2Go peut être insuffisant.
C'est vrai que c'est devenu un casse-tête, maintenant, le choix d'un ordinateur ...
Mais c'est sûr qu'avant toute chose il faudrait optimiser les tables.
ça, j'avais cru comprendre (en y mettant le temps il est vrai) que c'était fait. Ou on parle de créer une clef primaire avec un numéro auto ?
