Mon application est actuellement développée sous VB.
Comme c'est une application qui devient trop conséquente pour du VB et que
je me mets de plus en plus à écrire (et à apprécier) le C++, je porte
doucement les fonctions dans une DLL faites en C++ (BCB) que le programme en
VB (pour finir il ne vas rester que l'interface utilisateur) appelle.
De plus en plus, il va y avoir des données à transiter entre le prog VB et
la DLL C++. En ce moment, je commence à porter des fonctions dites
"critiques" ou l'échange de données va etre bcp plus important (tableaux,
fréquence d'appel, ...).
Je voudrais savoir si la séparation entre les fonctions (appelées) de la DLL
et les fonctions (appelantes) du programme principal implique une
gymnastique particuliere de la part de l'OS, auquel cas il n'est pas
judicieux de porter mes fonctions crtiques - ou - il n'y a aucune différence
entre le fait que la fonction soit dans une DLL ou dans le programme
principale pour la "qualité" de l'appel...
Meme question dans le cas où le programme est en C++...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
PurL
PurL wrote:
Bonjour,
Mon application est actuellement développée sous VB. Comme c'est une application qui devient trop conséquente pour du VB et que je me mets de plus en plus à écrire (et à apprécier) le C++, je porte doucement les fonctions dans une DLL faites en C++ (BCB) que le programme en VB (pour finir il ne vas rester que l'interface utilisateur) appelle. De plus en plus, il va y avoir des données à transiter entre le prog VB et la DLL C++. En ce moment, je commence à porter des fonctions dites "critiques" ou l'échange de données va etre bcp plus important (tableaux, fréquence d'appel, ...). Je voudrais savoir si la séparation entre les fonctions (appelées) de la DLL et les fonctions (appelantes) du programme principal implique une gymnastique particuliere de la part de l'OS, auquel cas il n'est pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune différence entre le fait que la fonction soit dans une DLL ou dans le programme principale pour la "qualité" de l'appel...
c'est si nul que ca comme question pour mériter ça ? :)
PurL
PurL wrote:
Bonjour,
Mon application est actuellement développée sous VB.
Comme c'est une application qui devient trop conséquente pour du VB
et que je me mets de plus en plus à écrire (et à apprécier) le C++,
je porte doucement les fonctions dans une DLL faites en C++ (BCB) que
le programme en VB (pour finir il ne vas rester que l'interface
utilisateur) appelle. De plus en plus, il va y avoir des données à
transiter entre le prog VB et la DLL C++. En ce moment, je commence à
porter des fonctions dites "critiques" ou l'échange de données va
etre bcp plus important (tableaux, fréquence d'appel, ...).
Je voudrais savoir si la séparation entre les fonctions (appelées) de
la DLL et les fonctions (appelantes) du programme principal implique
une gymnastique particuliere de la part de l'OS, auquel cas il n'est
pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune
différence entre le fait que la fonction soit dans une DLL ou dans le
programme principale pour la "qualité" de l'appel...
c'est si nul que ca comme question pour mériter ça ? :)
Mon application est actuellement développée sous VB. Comme c'est une application qui devient trop conséquente pour du VB et que je me mets de plus en plus à écrire (et à apprécier) le C++, je porte doucement les fonctions dans une DLL faites en C++ (BCB) que le programme en VB (pour finir il ne vas rester que l'interface utilisateur) appelle. De plus en plus, il va y avoir des données à transiter entre le prog VB et la DLL C++. En ce moment, je commence à porter des fonctions dites "critiques" ou l'échange de données va etre bcp plus important (tableaux, fréquence d'appel, ...). Je voudrais savoir si la séparation entre les fonctions (appelées) de la DLL et les fonctions (appelantes) du programme principal implique une gymnastique particuliere de la part de l'OS, auquel cas il n'est pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune différence entre le fait que la fonction soit dans une DLL ou dans le programme principale pour la "qualité" de l'appel...
c'est si nul que ca comme question pour mériter ça ? :)
PurL
Lo
"PurL" a écrit
> Mon application est actuellement développée sous VB. > Comme c'est une application qui devient trop conséquente pour du VB > et que je me mets de plus en plus à écrire (et à apprécier) le C++, > je porte doucement les fonctions dans une DLL faites en C++ (BCB) que > le programme en VB (pour finir il ne vas rester que l'interface > utilisateur) appelle. De plus en plus, il va y avoir des données à > transiter entre le prog VB et la DLL C++. En ce moment, je commence à > porter des fonctions dites "critiques" ou l'échange de données va > etre bcp plus important (tableaux, fréquence d'appel, ...). > Je voudrais savoir si la séparation entre les fonctions (appelées) de > la DLL et les fonctions (appelantes) du programme principal implique > une gymnastique particuliere de la part de l'OS, auquel cas il n'est > pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune > différence entre le fait que la fonction soit dans une DLL ou dans le > programme principale pour la "qualité" de l'appel...
c'est si nul que ca comme question pour mériter ça ? :)
J'en sais trop rien, mais comme t'as l'air de vouloir une réponse à tout pris, je te donne un point de vue.
Vu le nombre de programmes qui sont cassés en DLLs, c'est que ca doit pas changer grand chose. D'ailleurs pour les jeux par exemple qui sont des applications tres gourmandes en performance, enormement d'appels sont situés dans des DLLs ( directx, opengl etc ... ).
Loic.
"PurL" a écrit
> Mon application est actuellement développée sous VB.
> Comme c'est une application qui devient trop conséquente pour du VB
> et que je me mets de plus en plus à écrire (et à apprécier) le C++,
> je porte doucement les fonctions dans une DLL faites en C++ (BCB) que
> le programme en VB (pour finir il ne vas rester que l'interface
> utilisateur) appelle. De plus en plus, il va y avoir des données à
> transiter entre le prog VB et la DLL C++. En ce moment, je commence à
> porter des fonctions dites "critiques" ou l'échange de données va
> etre bcp plus important (tableaux, fréquence d'appel, ...).
> Je voudrais savoir si la séparation entre les fonctions (appelées) de
> la DLL et les fonctions (appelantes) du programme principal implique
> une gymnastique particuliere de la part de l'OS, auquel cas il n'est
> pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune
> différence entre le fait que la fonction soit dans une DLL ou dans le
> programme principale pour la "qualité" de l'appel...
c'est si nul que ca comme question pour mériter ça ? :)
J'en sais trop rien, mais comme t'as l'air de vouloir une réponse à tout
pris, je te donne un point de vue.
Vu le nombre de programmes qui sont cassés en DLLs, c'est que ca doit pas
changer grand chose. D'ailleurs pour les jeux par exemple qui sont des
applications tres gourmandes en performance, enormement d'appels sont situés
dans des DLLs ( directx, opengl etc ... ).
> Mon application est actuellement développée sous VB. > Comme c'est une application qui devient trop conséquente pour du VB > et que je me mets de plus en plus à écrire (et à apprécier) le C++, > je porte doucement les fonctions dans une DLL faites en C++ (BCB) que > le programme en VB (pour finir il ne vas rester que l'interface > utilisateur) appelle. De plus en plus, il va y avoir des données à > transiter entre le prog VB et la DLL C++. En ce moment, je commence à > porter des fonctions dites "critiques" ou l'échange de données va > etre bcp plus important (tableaux, fréquence d'appel, ...). > Je voudrais savoir si la séparation entre les fonctions (appelées) de > la DLL et les fonctions (appelantes) du programme principal implique > une gymnastique particuliere de la part de l'OS, auquel cas il n'est > pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune > différence entre le fait que la fonction soit dans une DLL ou dans le > programme principale pour la "qualité" de l'appel...
c'est si nul que ca comme question pour mériter ça ? :)
J'en sais trop rien, mais comme t'as l'air de vouloir une réponse à tout pris, je te donne un point de vue.
Vu le nombre de programmes qui sont cassés en DLLs, c'est que ca doit pas changer grand chose. D'ailleurs pour les jeux par exemple qui sont des applications tres gourmandes en performance, enormement d'appels sont situés dans des DLLs ( directx, opengl etc ... ).
Loic.
PurL
> J'en sais trop rien, mais comme t'as l'air de vouloir une réponse à tout pris, je te donne un point de vue.
Merci :)
Vu le nombre de programmes qui sont cassés en DLLs, c'est que ca doit pas changer grand chose. D'ailleurs pour les jeux par exemple qui sont des applications tres gourmandes en performance, enormement d'appels sont situés dans des DLLs ( directx, opengl etc ... ).
C'est une bonne remarque...
PurL
> J'en sais trop rien, mais comme t'as l'air de vouloir une réponse à
tout pris, je te donne un point de vue.
Merci :)
Vu le nombre de programmes qui sont cassés en DLLs, c'est que ca doit
pas changer grand chose. D'ailleurs pour les jeux par exemple qui
sont des applications tres gourmandes en performance, enormement
d'appels sont situés dans des DLLs ( directx, opengl etc ... ).
> J'en sais trop rien, mais comme t'as l'air de vouloir une réponse à tout pris, je te donne un point de vue.
Merci :)
Vu le nombre de programmes qui sont cassés en DLLs, c'est que ca doit pas changer grand chose. D'ailleurs pour les jeux par exemple qui sont des applications tres gourmandes en performance, enormement d'appels sont situés dans des DLLs ( directx, opengl etc ... ).
C'est une bonne remarque...
PurL
Arnaud Debaene
PurL wrote:
Bonjour,
Mon application est actuellement développée sous VB. Comme c'est une application qui devient trop conséquente pour du VB et que je me mets de plus en plus à écrire (et à apprécier) le C++, je porte doucement les fonctions dans une DLL faites en C++ (BCB) que le programme en VB (pour finir il ne vas rester que l'interface utilisateur) appelle. De plus en plus, il va y avoir des données à transiter entre le prog VB et la DLL C++. En ce moment, je commence à porter des fonctions dites "critiques" ou l'échange de données va etre bcp plus important (tableaux, fréquence d'appel, ...). Je voudrais savoir si la séparation entre les fonctions (appelées) de la DLL et les fonctions (appelantes) du programme principal implique une gymnastique particuliere de la part de l'OS, auquel cas il n'est pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune différence entre le fait que la fonction soit dans une DLL ou dans le programme principale pour la "qualité" de l'appel...
Meme question dans le cas où le programme est en C++...
Le fait d'appeler une fonction dans un autre module a un coup faible mais non nul : Il y a une indirection de pointeur de plus pour trouver l'adresse réelle de la fonction. A part pour des fonctions triviales appelées en boucle sérrée, la différence est généralement négligeable.
PS : Si des bibliothèques "hautes performances" comme DirectX sont stockées dans des DLL, ce n'est pas pour des raisons de performances (ca a un impact négatif) mais pour des raisons de facilité de distribution.
Arnaud
Merci,
PurL.
PurL wrote:
Bonjour,
Mon application est actuellement développée sous VB.
Comme c'est une application qui devient trop conséquente pour du VB
et que je me mets de plus en plus à écrire (et à apprécier) le C++,
je porte doucement les fonctions dans une DLL faites en C++ (BCB) que
le programme en VB (pour finir il ne vas rester que l'interface
utilisateur) appelle.
De plus en plus, il va y avoir des données à transiter entre le prog
VB et la DLL C++. En ce moment, je commence à porter des fonctions
dites "critiques" ou l'échange de données va etre bcp plus important
(tableaux, fréquence d'appel, ...).
Je voudrais savoir si la séparation entre les fonctions (appelées) de
la DLL et les fonctions (appelantes) du programme principal implique
une gymnastique particuliere de la part de l'OS, auquel cas il n'est
pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune
différence entre le fait que la fonction soit dans une DLL ou dans le
programme principale pour la "qualité" de l'appel...
Meme question dans le cas où le programme est en C++...
Le fait d'appeler une fonction dans un autre module a un coup faible mais
non nul : Il y a une indirection de pointeur de plus pour trouver l'adresse
réelle de la fonction. A part pour des fonctions triviales appelées en
boucle sérrée, la différence est généralement négligeable.
PS : Si des bibliothèques "hautes performances" comme DirectX sont stockées
dans des DLL, ce n'est pas pour des raisons de performances (ca a un impact
négatif) mais pour des raisons de facilité de distribution.
Mon application est actuellement développée sous VB. Comme c'est une application qui devient trop conséquente pour du VB et que je me mets de plus en plus à écrire (et à apprécier) le C++, je porte doucement les fonctions dans une DLL faites en C++ (BCB) que le programme en VB (pour finir il ne vas rester que l'interface utilisateur) appelle. De plus en plus, il va y avoir des données à transiter entre le prog VB et la DLL C++. En ce moment, je commence à porter des fonctions dites "critiques" ou l'échange de données va etre bcp plus important (tableaux, fréquence d'appel, ...). Je voudrais savoir si la séparation entre les fonctions (appelées) de la DLL et les fonctions (appelantes) du programme principal implique une gymnastique particuliere de la part de l'OS, auquel cas il n'est pas judicieux de porter mes fonctions crtiques - ou - il n'y a aucune différence entre le fait que la fonction soit dans une DLL ou dans le programme principale pour la "qualité" de l'appel...
Meme question dans le cas où le programme est en C++...
Le fait d'appeler une fonction dans un autre module a un coup faible mais non nul : Il y a une indirection de pointeur de plus pour trouver l'adresse réelle de la fonction. A part pour des fonctions triviales appelées en boucle sérrée, la différence est généralement négligeable.
PS : Si des bibliothèques "hautes performances" comme DirectX sont stockées dans des DLL, ce n'est pas pour des raisons de performances (ca a un impact négatif) mais pour des raisons de facilité de distribution.
Arnaud
Merci,
PurL.
MALIS Pierre-Yves
Moi j'aurais la meme question dans le cas ou on decoupe son programme en tout un tas de petites fonctions (c'est mon cas) savoir s'il n'y a pas de perte de temps pour acceder a chaque fois au differentes fonctions.
Pi
Moi j'aurais la meme question dans le cas ou on decoupe son programme en tout
un tas de petites fonctions (c'est mon cas) savoir s'il n'y a pas de perte de
temps pour acceder a chaque fois au differentes fonctions.
Moi j'aurais la meme question dans le cas ou on decoupe son programme en tout un tas de petites fonctions (c'est mon cas) savoir s'il n'y a pas de perte de temps pour acceder a chaque fois au differentes fonctions.
Pi
Cyrille \cns\ Szymanski
> Moi j'aurais la meme question dans le cas ou on decoupe son programme en tout un tas de petites fonctions (c'est mon cas) savoir s'il n'y a pas de perte de temps pour acceder a chaque fois au differentes fonctions.
Pi
Il y a perte de temps (les instructions de saut, passage d'arguments etc.) et de mémoire (il faut reconstruire un "stack frame" à chaque appel). Mais les compilateurs sont censés optimiser cela dans un grand nombre de cas (fonctions inline etc).
Alors le tout est de savoir si rendre le programme plus compliqué et moins modulaire vaut le gain en performance. Perso je ne le pense pas et je continue de faire plein de petites fonctions.
Le point à voir est la différence entre appel statique et dynamique. Un appel statique est relativement peu coûteux car au moment de l'édition de liens, le compilateur sait où se trouve la fonction. Le code qu'il génère est du type "saut à l'adresse 0x12345678.
Pour un appel dynamique c'est différent. Le coût est supérieur car la démarche est du type "charger la bibliothèque (s'il le faut)", "récupérer la table d'adresses" puis lors de l'appel il faut "chercher dans la table l'adresse de la fonction à appeler" et "appeler la fonction".
> Moi j'aurais la meme question dans le cas ou on decoupe son programme
en tout un tas de petites fonctions (c'est mon cas) savoir s'il n'y a
pas de perte de temps pour acceder a chaque fois au differentes
fonctions.
Pi
Il y a perte de temps (les instructions de saut, passage d'arguments
etc.) et de mémoire (il faut reconstruire un "stack frame" à chaque
appel). Mais les compilateurs sont censés optimiser cela dans un grand
nombre de cas (fonctions inline etc).
Alors le tout est de savoir si rendre le programme plus compliqué et
moins modulaire vaut le gain en performance. Perso je ne le pense pas et
je continue de faire plein de petites fonctions.
Le point à voir est la différence entre appel statique et dynamique. Un
appel statique est relativement peu coûteux car au moment de l'édition de
liens, le compilateur sait où se trouve la fonction. Le code qu'il génère
est du type "saut à l'adresse 0x12345678.
Pour un appel dynamique c'est différent. Le coût est supérieur car la
démarche est du type "charger la bibliothèque (s'il le faut)", "récupérer
la table d'adresses" puis lors de l'appel il faut "chercher dans la table
l'adresse de la fonction à appeler" et "appeler la fonction".
> Moi j'aurais la meme question dans le cas ou on decoupe son programme en tout un tas de petites fonctions (c'est mon cas) savoir s'il n'y a pas de perte de temps pour acceder a chaque fois au differentes fonctions.
Pi
Il y a perte de temps (les instructions de saut, passage d'arguments etc.) et de mémoire (il faut reconstruire un "stack frame" à chaque appel). Mais les compilateurs sont censés optimiser cela dans un grand nombre de cas (fonctions inline etc).
Alors le tout est de savoir si rendre le programme plus compliqué et moins modulaire vaut le gain en performance. Perso je ne le pense pas et je continue de faire plein de petites fonctions.
Le point à voir est la différence entre appel statique et dynamique. Un appel statique est relativement peu coûteux car au moment de l'édition de liens, le compilateur sait où se trouve la fonction. Le code qu'il génère est du type "saut à l'adresse 0x12345678.
Pour un appel dynamique c'est différent. Le coût est supérieur car la démarche est du type "charger la bibliothèque (s'il le faut)", "récupérer la table d'adresses" puis lors de l'appel il faut "chercher dans la table l'adresse de la fonction à appeler" et "appeler la fonction".
