Existe-t-il un moyen (une instruction, une API, ...) qui permet de
savoir si mon programme va entrer ou sortir d'une phase de swapping avec
le disque dur ?
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
Sylvain
ChP wrote on 05/10/2006 00:10:
Bonjour à toutes et à tous,
Existe-t-il un moyen (une instruction, une API, ...) qui permet de savoir si mon programme va entrer ou sortir d'une phase de swapping avec le disque dur ?
une API utilisée par un soft pour pouvoir s'il est en cache disque et donc non en cours d'exécution (y compris de cette API), c'est bien cela?
je ne crois pas que cela n'existe, ni que cela servirait - s'il a été swappé c'est qu'il ne sert pas / n'est pas utilisé.
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
Sylvain.
ChP wrote on 05/10/2006 00:10:
Bonjour à toutes et à tous,
Existe-t-il un moyen (une instruction, une API, ...) qui permet de
savoir si mon programme va entrer ou sortir d'une phase de swapping avec
le disque dur ?
une API utilisée par un soft pour pouvoir s'il est en cache disque et
donc non en cours d'exécution (y compris de cette API), c'est bien cela?
je ne crois pas que cela n'existe, ni que cela servirait - s'il a été
swappé c'est qu'il ne sert pas / n'est pas utilisé.
une autre question, ayant plus d'incidence applicative, serait est-ce
que mes données (que l'on suppose très larges) sont ou non swappées,
certains choix sur leur traitement pourraient en être influés.
Existe-t-il un moyen (une instruction, une API, ...) qui permet de savoir si mon programme va entrer ou sortir d'une phase de swapping avec le disque dur ?
une API utilisée par un soft pour pouvoir s'il est en cache disque et donc non en cours d'exécution (y compris de cette API), c'est bien cela?
je ne crois pas que cela n'existe, ni que cela servirait - s'il a été swappé c'est qu'il ne sert pas / n'est pas utilisé.
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
Sylvain.
ChP
Sylvain a écrit :
ChP wrote on 05/10/2006 00:10:
Bonjour à toutes et à tous,
Existe-t-il un moyen (une instruction, une API, ...) qui permet de savoir si mon programme va entrer ou sortir d'une phase de swapping avec le disque dur ?
une API utilisée par un soft pour pouvoir s'il est en cache disque et donc non en cours d'exécution (y compris de cette API), c'est bien cela?
je ne crois pas que cela n'existe, ni que cela servirait - s'il a été swappé c'est qu'il ne sert pas / n'est pas utilisé.
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
Sylvain.
Sylvain a écrit :
ChP wrote on 05/10/2006 00:10:
Bonjour à toutes et à tous,
Existe-t-il un moyen (une instruction, une API, ...) qui permet de
savoir si mon programme va entrer ou sortir d'une phase de swapping
avec le disque dur ?
une API utilisée par un soft pour pouvoir s'il est en cache disque et
donc non en cours d'exécution (y compris de cette API), c'est bien cela?
je ne crois pas que cela n'existe, ni que cela servirait - s'il a été
swappé c'est qu'il ne sert pas / n'est pas utilisé.
une autre question, ayant plus d'incidence applicative, serait est-ce
que mes données (que l'on suppose très larges) sont ou non swappées,
certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
Existe-t-il un moyen (une instruction, une API, ...) qui permet de savoir si mon programme va entrer ou sortir d'une phase de swapping avec le disque dur ?
une API utilisée par un soft pour pouvoir s'il est en cache disque et donc non en cours d'exécution (y compris de cette API), c'est bien cela?
je ne crois pas que cela n'existe, ni que cela servirait - s'il a été swappé c'est qu'il ne sert pas / n'est pas utilisé.
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
Sylvain.
Sylvain
ChP wrote on 05/10/2006 08:25:
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
la gestion de la mémoire étant supposée transparente, je ne crois pas qu'une fonction d'interrogation directe existe (pour ce status in RAM vs in cache), cependant le memory manager propose des API telle VirtualAlloc qui permet d'obtenir un bloc qui ne sera pas swappé, cela peut répondre à une partie de la question en l'évitant; les API AWE (Address Windowing Extensions) permettent également d'éviter le swapping - voir les récents posts d'Arnold pour des explications sur le fonctionnement de ma mémoire.
Sylvain.
ChP wrote on 05/10/2006 08:25:
une autre question, ayant plus d'incidence applicative, serait est-ce
que mes données (que l'on suppose très larges) sont ou non swappées,
certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
la gestion de la mémoire étant supposée transparente, je ne crois pas
qu'une fonction d'interrogation directe existe (pour ce status in RAM vs
in cache), cependant le memory manager propose des API telle
VirtualAlloc qui permet d'obtenir un bloc qui ne sera pas swappé, cela
peut répondre à une partie de la question en l'évitant; les API AWE
(Address Windowing Extensions) permettent également d'éviter le swapping
- voir les récents posts d'Arnold pour des explications sur le
fonctionnement de ma mémoire.
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
la gestion de la mémoire étant supposée transparente, je ne crois pas qu'une fonction d'interrogation directe existe (pour ce status in RAM vs in cache), cependant le memory manager propose des API telle VirtualAlloc qui permet d'obtenir un bloc qui ne sera pas swappé, cela peut répondre à une partie de la question en l'évitant; les API AWE (Address Windowing Extensions) permettent également d'éviter le swapping - voir les récents posts d'Arnold pour des explications sur le fonctionnement de ma mémoire.
Sylvain.
ChP
Sylvain a écrit :
ChP wrote on 05/10/2006 08:25:
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
la gestion de la mémoire étant supposée transparente, je ne crois pas qu'une fonction d'interrogation directe existe (pour ce status in RAM vs in cache), cependant le memory manager propose des API telle VirtualAlloc qui permet d'obtenir un bloc qui ne sera pas swappé, cela peut répondre à une partie de la question en l'évitant; les API AWE (Address Windowing Extensions) permettent également d'éviter le swapping - voir les récents posts d'Arnold pour des explications sur le fonctionnement de ma mémoire.
Sylvain.
L'article de Arnold est très instructif, mais il conduit à la gestion de la mémoire par Windows et qui est moult fois plus compliquée encore. Ce n'est plus de mon niveau.
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je peux y adjoindre des appels directs aux API) de gestion d'images qui peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas maître de la gestion de la mémoire. Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens, c'est planté, ça n'avance plus !"
Merci de votre aide.
Pierre.
Sylvain a écrit :
ChP wrote on 05/10/2006 08:25:
une autre question, ayant plus d'incidence applicative, serait est-ce
que mes données (que l'on suppose très larges) sont ou non swappées,
certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
la gestion de la mémoire étant supposée transparente, je ne crois pas
qu'une fonction d'interrogation directe existe (pour ce status in RAM vs
in cache), cependant le memory manager propose des API telle
VirtualAlloc qui permet d'obtenir un bloc qui ne sera pas swappé, cela
peut répondre à une partie de la question en l'évitant; les API AWE
(Address Windowing Extensions) permettent également d'éviter le swapping
- voir les récents posts d'Arnold pour des explications sur le
fonctionnement de ma mémoire.
Sylvain.
L'article de Arnold est très instructif, mais il conduit à la gestion de
la mémoire par Windows et qui est moult fois plus compliquée encore. Ce
n'est plus de mon niveau.
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je
peux y adjoindre des appels directs aux API) de gestion d'images qui
peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas
maître de la gestion de la mémoire. Mon but serait simplement d'avertir
l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens,
c'est planté, ça n'avance plus !"
une autre question, ayant plus d'incidence applicative, serait est-ce que mes données (que l'on suppose très larges) sont ou non swappées, certains choix sur leur traitement pourraient en être influés.
c'est bien des données dont je parle, pas du programme lui même.
la gestion de la mémoire étant supposée transparente, je ne crois pas qu'une fonction d'interrogation directe existe (pour ce status in RAM vs in cache), cependant le memory manager propose des API telle VirtualAlloc qui permet d'obtenir un bloc qui ne sera pas swappé, cela peut répondre à une partie de la question en l'évitant; les API AWE (Address Windowing Extensions) permettent également d'éviter le swapping - voir les récents posts d'Arnold pour des explications sur le fonctionnement de ma mémoire.
Sylvain.
L'article de Arnold est très instructif, mais il conduit à la gestion de la mémoire par Windows et qui est moult fois plus compliquée encore. Ce n'est plus de mon niveau.
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je peux y adjoindre des appels directs aux API) de gestion d'images qui peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas maître de la gestion de la mémoire. Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens, c'est planté, ça n'avance plus !"
Merci de votre aide.
Pierre.
Arnold McDonald \(AMcD\)
ChP wrote:
L'article de Arnold est très instructif, mais il conduit à la gestion de la mémoire par Windows et qui est moult fois plus compliquée encore.
Oui, je dois poster un de ces jours la suite, la gestion de la mémoire sous Windows. Simplement, la dernière fois, il y en avait pour 21 Ko de généralités traitées assez rapidement, c'est déjà long. Pour faire le même truc sous Windows, ça serait au moins 3 ou 4 fois plus long (et encore, je suis modeste). Faut que je trouve la motiv'...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
ChP wrote:
L'article de Arnold est très instructif, mais il conduit à la gestion
de la mémoire par Windows et qui est moult fois plus compliquée
encore.
Oui, je dois poster un de ces jours la suite, la gestion de la mémoire sous
Windows. Simplement, la dernière fois, il y en avait pour 21 Ko de
généralités traitées assez rapidement, c'est déjà long. Pour faire le même
truc sous Windows, ça serait au moins 3 ou 4 fois plus long (et encore, je
suis modeste). Faut que je trouve la motiv'...
L'article de Arnold est très instructif, mais il conduit à la gestion de la mémoire par Windows et qui est moult fois plus compliquée encore.
Oui, je dois poster un de ces jours la suite, la gestion de la mémoire sous Windows. Simplement, la dernière fois, il y en avait pour 21 Ko de généralités traitées assez rapidement, c'est déjà long. Pour faire le même truc sous Windows, ça serait au moins 3 ou 4 fois plus long (et encore, je suis modeste). Faut que je trouve la motiv'...
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
ChP
Arnold McDonald (AMcD) a écrit :
ChP wrote:
L'article de Arnold est très instructif, mais il conduit à la gestion de la mémoire par Windows et qui est moult fois plus compliquée encore.
Oui, je dois poster un de ces jours la suite, la gestion de la mémoire sous Windows. Simplement, la dernière fois, il y en avait pour 21 Ko de généralités traitées assez rapidement, c'est déjà long. Pour faire le même truc sous Windows, ça serait au moins 3 ou 4 fois plus long (et encore, je suis modeste). Faut que je trouve la motiv'...
Je te comprends !
Pierre
Arnold McDonald (AMcD) a écrit :
ChP wrote:
L'article de Arnold est très instructif, mais il conduit à la gestion
de la mémoire par Windows et qui est moult fois plus compliquée
encore.
Oui, je dois poster un de ces jours la suite, la gestion de la mémoire sous
Windows. Simplement, la dernière fois, il y en avait pour 21 Ko de
généralités traitées assez rapidement, c'est déjà long. Pour faire le même
truc sous Windows, ça serait au moins 3 ou 4 fois plus long (et encore, je
suis modeste). Faut que je trouve la motiv'...
L'article de Arnold est très instructif, mais il conduit à la gestion de la mémoire par Windows et qui est moult fois plus compliquée encore.
Oui, je dois poster un de ces jours la suite, la gestion de la mémoire sous Windows. Simplement, la dernière fois, il y en avait pour 21 Ko de généralités traitées assez rapidement, c'est déjà long. Pour faire le même truc sous Windows, ça serait au moins 3 ou 4 fois plus long (et encore, je suis modeste). Faut que je trouve la motiv'...
Je te comprends !
Pierre
Sylvain
ChP wrote on 05/10/2006 13:13:
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je peux y adjoindre des appels directs aux API) de gestion d'images qui peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas maître de la gestion de la mémoire.
je vous confirme! tellement pas maitre que s'il existait une API isInSwap vous ne pourrez certainement pas lui passer un pointeur Delphi qui sort du memory manager Delphi.
le partie que vous pouvez maitriser est ce qui a vraiment besoin d'être en RAM - si c'est du BMP 32 bits à 300 dpi et format A0, pas bcp de choix, si par contre vous générez les images (ray tracing, vectoriel, etc) vous pouvez travailler sur des rendus basse résolution et ne faire le calcul haute déf. que sur demande.
Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens, c'est planté, ça n'avance plus !"
avertissez-le simplement en expliquant, documentant, que l'on ne traite pas des images 1go avec 256/512mo de RAM mais plutôt avec 2go. pour le reste mettez un sablier où une progress-bar infini, il verra qu'il se passe qlq chose.
entre les 2 (définir le statut de chaque bloc mémoire et le simple sablier) vous pouvez simplement comparer la taille des images à ouvrir/créer et celle de la mémoire physique installée, vous alerterez alors l'utilisateur du risque de lenteur si les images sont trop grosses (par rapport à la mem. physique).
Sylvain.
ChP wrote on 05/10/2006 13:13:
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je
peux y adjoindre des appels directs aux API) de gestion d'images qui
peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas
maître de la gestion de la mémoire.
je vous confirme! tellement pas maitre que s'il existait une API
isInSwap vous ne pourrez certainement pas lui passer un pointeur Delphi
qui sort du memory manager Delphi.
le partie que vous pouvez maitriser est ce qui a vraiment besoin d'être
en RAM - si c'est du BMP 32 bits à 300 dpi et format A0, pas bcp de
choix, si par contre vous générez les images (ray tracing, vectoriel,
etc) vous pouvez travailler sur des rendus basse résolution et ne faire
le calcul haute déf. que sur demande.
Mon but serait simplement d'avertir l'utilisateur lorsqu'il
y a swapping pour qu'il ne se dise pas : "tiens, c'est planté,
ça n'avance plus !"
avertissez-le simplement en expliquant, documentant, que l'on ne traite
pas des images 1go avec 256/512mo de RAM mais plutôt avec 2go.
pour le reste mettez un sablier où une progress-bar infini, il verra
qu'il se passe qlq chose.
entre les 2 (définir le statut de chaque bloc mémoire et le simple
sablier) vous pouvez simplement comparer la taille des images à
ouvrir/créer et celle de la mémoire physique installée, vous alerterez
alors l'utilisateur du risque de lenteur si les images sont trop grosses
(par rapport à la mem. physique).
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je peux y adjoindre des appels directs aux API) de gestion d'images qui peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas maître de la gestion de la mémoire.
je vous confirme! tellement pas maitre que s'il existait une API isInSwap vous ne pourrez certainement pas lui passer un pointeur Delphi qui sort du memory manager Delphi.
le partie que vous pouvez maitriser est ce qui a vraiment besoin d'être en RAM - si c'est du BMP 32 bits à 300 dpi et format A0, pas bcp de choix, si par contre vous générez les images (ray tracing, vectoriel, etc) vous pouvez travailler sur des rendus basse résolution et ne faire le calcul haute déf. que sur demande.
Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens, c'est planté, ça n'avance plus !"
avertissez-le simplement en expliquant, documentant, que l'on ne traite pas des images 1go avec 256/512mo de RAM mais plutôt avec 2go. pour le reste mettez un sablier où une progress-bar infini, il verra qu'il se passe qlq chose.
entre les 2 (définir le statut de chaque bloc mémoire et le simple sablier) vous pouvez simplement comparer la taille des images à ouvrir/créer et celle de la mémoire physique installée, vous alerterez alors l'utilisateur du risque de lenteur si les images sont trop grosses (par rapport à la mem. physique).
Sylvain.
ChP
Sylvain a écrit :
ChP wrote on 05/10/2006 13:13:
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je peux y adjoindre des appels directs aux API) de gestion d'images qui peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas maître de la gestion de la mémoire.
je vous confirme! tellement pas maitre que s'il existait une API isInSwap vous ne pourrez certainement pas lui passer un pointeur Delphi qui sort du memory manager Delphi.
le partie que vous pouvez maitriser est ce qui a vraiment besoin d'être en RAM - si c'est du BMP 32 bits à 300 dpi et format A0, pas bcp de choix, si par contre vous générez les images (ray tracing, vectoriel, etc) vous pouvez travailler sur des rendus basse résolution et ne faire le calcul haute déf. que sur demande.
Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens, c'est planté, ça n'avance plus !"
avertissez-le simplement en expliquant, documentant, que l'on ne traite pas des images 1go avec 256/512mo de RAM mais plutôt avec 2go. pour le reste mettez un sablier où une progress-bar infini, il verra qu'il se passe qlq chose.
Le sablier et le progressbar : c'est fait.
entre les 2 (définir le statut de chaque bloc mémoire et le simple sablier) vous pouvez simplement comparer la taille des images à ouvrir/créer et celle de la mémoire physique installée, vous alerterez alors l'utilisateur du risque de lenteur si les images sont trop grosses (par rapport à la mem. physique).
Sylvain.
Merci pour ces conseils.
Pierre
Sylvain a écrit :
ChP wrote on 05/10/2006 13:13:
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je
peux y adjoindre des appels directs aux API) de gestion d'images qui
peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas
maître de la gestion de la mémoire.
je vous confirme! tellement pas maitre que s'il existait une API
isInSwap vous ne pourrez certainement pas lui passer un pointeur Delphi
qui sort du memory manager Delphi.
le partie que vous pouvez maitriser est ce qui a vraiment besoin d'être
en RAM - si c'est du BMP 32 bits à 300 dpi et format A0, pas bcp de
choix, si par contre vous générez les images (ray tracing, vectoriel,
etc) vous pouvez travailler sur des rendus basse résolution et ne faire
le calcul haute déf. que sur demande.
Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a
swapping pour qu'il ne se dise pas : "tiens, c'est planté,
ça n'avance plus !"
avertissez-le simplement en expliquant, documentant, que l'on ne traite
pas des images 1go avec 256/512mo de RAM mais plutôt avec 2go.
pour le reste mettez un sablier où une progress-bar infini, il verra
qu'il se passe qlq chose.
Le sablier et le progressbar : c'est fait.
entre les 2 (définir le statut de chaque bloc mémoire et le simple
sablier) vous pouvez simplement comparer la taille des images à
ouvrir/créer et celle de la mémoire physique installée, vous alerterez
alors l'utilisateur du risque de lenteur si les images sont trop grosses
(par rapport à la mem. physique).
En ce qui me concerne, j'ai réalisé un programme (en DELPHI 6 mais je peux y adjoindre des appels directs aux API) de gestion d'images qui peuvent utiliser en mémoire plus d'un GB. Je ne suis absolument pas maître de la gestion de la mémoire.
je vous confirme! tellement pas maitre que s'il existait une API isInSwap vous ne pourrez certainement pas lui passer un pointeur Delphi qui sort du memory manager Delphi.
le partie que vous pouvez maitriser est ce qui a vraiment besoin d'être en RAM - si c'est du BMP 32 bits à 300 dpi et format A0, pas bcp de choix, si par contre vous générez les images (ray tracing, vectoriel, etc) vous pouvez travailler sur des rendus basse résolution et ne faire le calcul haute déf. que sur demande.
Mon but serait simplement d'avertir l'utilisateur lorsqu'il y a swapping pour qu'il ne se dise pas : "tiens, c'est planté, ça n'avance plus !"
avertissez-le simplement en expliquant, documentant, que l'on ne traite pas des images 1go avec 256/512mo de RAM mais plutôt avec 2go. pour le reste mettez un sablier où une progress-bar infini, il verra qu'il se passe qlq chose.
Le sablier et le progressbar : c'est fait.
entre les 2 (définir le statut de chaque bloc mémoire et le simple sablier) vous pouvez simplement comparer la taille des images à ouvrir/créer et celle de la mémoire physique installée, vous alerterez alors l'utilisateur du risque de lenteur si les images sont trop grosses (par rapport à la mem. physique).
