OVH Cloud OVH Cloud

API Callback et Performances

6 réponses
Avatar
LiR
Bonjour à tous,

J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel
d'une fonction API de Windows qui fonctionne avec une fonction de retour
("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la
fonction callback EnhMetaFileProc.

L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la
fonction EnhMetaFileProc par Windows.

Le problème est le suivant :
Le projet VBA, qui était dans Word, fonctionnait très bien.
Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps
d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.

Quelqu'un aurait-il une information sur la lenteur des fonctions API
callback dans Access?

Un grand merci pour votre aide.

6 réponses

Avatar
Bonjour

A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access...
Ta base access est située sur un disque local ?
a+

--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------


"LiR" a écrit dans le message de news:
Bonjour à tous,

J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel
d'une fonction API de Windows qui fonctionne avec une fonction de retour
("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la
fonction callback EnhMetaFileProc.

L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la
fonction EnhMetaFileProc par Windows.

Le problème est le suivant :
Le projet VBA, qui était dans Word, fonctionnait très bien.
Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps
d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.

Quelqu'un aurait-il une information sur la lenteur des fonctions API
callback dans Access?

Un grand merci pour votre aide.


Avatar
LiR
Merci Anor de te pencher sur mon problème,

Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère
près.
Ils sont exécutés sur la même machine en local.

Je vien en revanche de faire un test très utile : dans ma fonction callback,
il y avait une instruction DoEvents.

Je l'ai retirée et les performances sont alors identiques dans Word et dans
Access.

La question serait donc :

Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?




Bonjour

A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access...
Ta base access est située sur un disque local ?
a+

--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------


"LiR" a écrit dans le message de news:
Bonjour à tous,

J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel
d'une fonction API de Windows qui fonctionne avec une fonction de retour
("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la
fonction callback EnhMetaFileProc.

L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la
fonction EnhMetaFileProc par Windows.

Le problème est le suivant :
Le projet VBA, qui était dans Word, fonctionnait très bien.
Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps
d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.

Quelqu'un aurait-il une information sur la lenteur des fonctions API
callback dans Access?

Un grand merci pour votre aide.







Avatar
Salut

eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))

trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate
que le code se déroule trop vite pour rendre le résultat attendu.

Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access
et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)

a+
Arnaud

"LiR" a écrit dans le message de news:
Merci Anor de te pencher sur mon problème,

Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère
près.
Ils sont exécutés sur la même machine en local.

Je vien en revanche de faire un test très utile : dans ma fonction callback,
il y avait une instruction DoEvents.

Je l'ai retirée et les performances sont alors identiques dans Word et dans
Access.

La question serait donc :

Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?




Avatar
LiR
En fait, comme je l'ai dit :
Les 2 projets VBA sont identiques au caractère près : le doEvents était dans
Word et fonctionnait très bien (il ne ralentissait pas l'exécution).

En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne
pas voir son écran se figer et aussi de prendre la main pour appuyer sur un
bouton "Annuler" afin de mettre fin à l'opération (malheureusement le
multithread n'existe pas en VBA)...

C'est quand même étrange que cette instruction ait des répercussions si
différentes dans Access et dans Word...


Salut

eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))

trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate
que le code se déroule trop vite pour rendre le résultat attendu.

Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access
et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)

a+
Arnaud

"LiR" a écrit dans le message de news:
Merci Anor de te pencher sur mon problème,

Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère
près.
Ils sont exécutés sur la même machine en local.

Je vien en revanche de faire un test très utile : dans ma fonction callback,
il y avait une instruction DoEvents.

Je l'ai retirée et les performances sont alors identiques dans Word et dans
Access.

La question serait donc :

Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?









Avatar
3stone
Salut,

"LiR"
| En fait, comme je l'ai dit :
| Les 2 projets VBA sont identiques au caractère près : le doEvents était dans
| Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
|
| En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne
| pas voir son écran se figer et aussi de prendre la main pour appuyer sur un
| bouton "Annuler" afin de mettre fin à l'opération (malheureusement le
| multithread n'existe pas en VBA)...
|
| C'est quand même étrange que cette instruction ait des répercussions si
| différentes dans Access et dans Word...

Pas tant que ca...

Access n'est pas Word. Et Access à la particularité de se réservé tout le
temps processeur et de ne lacher que ce que Windows demande.

Et, sur Access en tout cas il "consomme" beaucoup de temps.
Un simple test avec une boucle comprenant ou non un DoEvents montre
une différence de temps d'exécution très importante.


L'utilité d'un DoEvents n'a pas seulement, comme tu dis :

"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer
et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de
mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"

Cela va beaucoup plus loin !
Le DoEvents rend explicitement la main au système, qui sans cela est incapable
de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)

Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement
parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine
vba monopolisant toutes les ressources.


--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/
Avatar
LiR
Cela confirme bien ce que je pensais et c'est exactement la conclusion que
j'en avais tiré, au détail près qu'en l'occurence DoEvents rend la main à
Access (et non au "système" à qui, en outre, je l'ai donnée!).

Il y a cependant en pratique une diffférence entre un DoEvents localisé pour
permettre à un thread de terminer sa tâche (mode asynchrone a priori) et une
répétition de DoEvents pour "faire respirer" le système.

Je trouve juste étrange que passer la main au système revienne ici à
parmettre à Access de détruire les performances pour rien!

En conclusion, je le sais désormais et j'en tiendrai compte pour la suite.

Un grand merci à vous deux pour vous être penchés sur mon problème.


Salut,

"LiR"
| En fait, comme je l'ai dit :
| Les 2 projets VBA sont identiques au caractère près : le doEvents était dans
| Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
|
| En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne
| pas voir son écran se figer et aussi de prendre la main pour appuyer sur un
| bouton "Annuler" afin de mettre fin à l'opération (malheureusement le
| multithread n'existe pas en VBA)...
|
| C'est quand même étrange que cette instruction ait des répercussions si
| différentes dans Access et dans Word...

Pas tant que ca...

Access n'est pas Word. Et Access à la particularité de se réservé tout le
temps processeur et de ne lacher que ce que Windows demande.

Et, sur Access en tout cas il "consomme" beaucoup de temps.
Un simple test avec une boucle comprenant ou non un DoEvents montre
une différence de temps d'exécution très importante.


L'utilité d'un DoEvents n'a pas seulement, comme tu dis :

"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer
et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de
mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"

Cela va beaucoup plus loin !
Le DoEvents rend explicitement la main au système, qui sans cela est incapable
de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)

Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement
parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine
vba monopolisant toutes les ressources.


--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
Conseils MPFA: http://www.mpfa.info/