Windows 10 à peine installé et déjà de gros problèmes avec Photoshop

Démarré par psbez, Décembre 01, 2019, 17:00:40

« précédent - suivant »

psbez

Avec W7 mes DXO PL et PSE 15 fonctionnaient sans pb.
J'ai réussi, après 3 tentatives ( voir mon autre fil ci dessous ) à passer sur W10.
Maintenant j'ai de gros problèmes pour enregistrer mes fichiers photo, même petits : PSE me dit qu'il ne peut le faire car << la mémoire vive serait insuffisante>> Mes fichiers ne peuvent pas, non plus, être travaillés avec la Nik collection, car les images sont complètement brouillées
Qui, parmi vous, aurait eu ces pbs et comment les avez vous résolus. ?..
Merci d'avance de me donner la solution car cela « m'embête »  beaucoup

psbez

C'est moi, en 2015, qui a configuré ce PC avec <Capweb informatique pc>, basée dans le 29 ( St Servais ) pour la photo  :  Processeur i5, Ram 16 go, pas pour le jeu ! carte vidéo nvidia ge 630,. Je  maintiens toujours 200 GO de libres sur le DDI de 500 G0

psbez

Merci Stepbystep pour tes conseils : je vais m'y mettre demain !!

Samoreen

Problème connu. Normalement, la manip suivante, adaptée à la version de PS ou PSE corrige le problème :

- S'assurer que PSE ne tourne pas.
- Lancer Regedit et naviguer jusqu'à HKEY_CURRENT_USER\Software\Adobe\Photoshop Elements\xx.x (version de PSE)
- Clic-droit dans le panneau de droite | Nouvelle valeur de type DWORD 32-bit
- Nommer cette valeur OverridePhysicalMemoryMB
- Passer en mode decimal et entrer 8000 (voire plus en fonction de votre système)
- OK | Fermer Regedit | Relancer PSE

Le problème est que depuis la version 1803, la manière dont Windows retourne la mémoire disponible a changé. Mais PS et PSE continuent (ou on continué jusqu'à récemment) d'utiliser l'ancienne méthode et ne se sont pas adaptés. Cette manip remplace la valeur retournée par le système par la valeur entrée dans la registry ci-dessus.
Patrick

psbez

Merci à samoreen : le problème a été résolu pour le PC 16GO avec regedit
Par contre il persiste sur "le plus vieux" qui n'a que 4 GO et je vais faire comme l'a proposé stepbystep : je vais le passer à 8 GO
Merci beaucoup à vous deux, vous m'avez enlevé une belle épine du pied...

Samoreen

Citation de: psbez le Décembre 02, 2019, 22:17:45
Par contre il persiste sur "le plus vieux" qui n'a que 4 GO et je vais faire comme l'a proposé stepbystep : je vais le passer à 8 GO

S'il n'a que 4 Go, il faut entrer la valeur 4000 au lieu de 8000.
Patrick

Samoreen

Citation de: Stepbystep le Décembre 03, 2019, 10:37:48
4 go est un peu limite pour W10, surtout en retouche photo.

C'est certain. Je ne suggérais pas de rester à 4 Go. Mais temporairement, la modif dans Regedit devrait fonctionner également avec cette valeur (probablement avec un recours plus fréquent au fichier de pagination).
Patrick

egtegt²

Je crois qu'il vaut mieux oublier, si le PC commence à paginer, les performances vont carrément s'écrouler

Samoreen

Citation de: egtegt² le Décembre 03, 2019, 11:17:48
Je crois qu'il vaut mieux oublier, si le PC commence à paginer, les performances vont carrément s'écrouler

En fait, ça pagine tout le temps, quelle que soit la quantité de mémoire installée. Ce n'est pas un mécanisme complètement binaire. Le tout est de limiter le volume et la fréquence des échanges (en ajoutant de la mémoire physique) et de savoir dans quelles conditions et sur quel support ça pagine. On peut largement améliorer les performances en déportant la plus grosse partie du fichier de pagination vers une autre partition (un disque physique différent). On est obligé de garder un minimum sur le disque système (1 Go chez moi) mais on peut déporter le reste vers un espace dédié (chez moi, un vieux SSD de récup).

Le mécanisme de mémoire virtuelle de Windows ne sert pas qu'à procurer de l'espace mémoire aux programmes. Il sert bien sûr à stocker les données temporaires mais aussi à gérer les mappings nécessaires quand la quantité de données gérée par un programme devient très importante (c-à-d quand elle atteint des volumes qui sont de toute façon supérieurs à la quantité de mémoire physique disponible). Une image ouverte dans Photoshop et utilisant de nombreux calques, filtres dynamiques, etc. peut occuper un espace mémoire astronomique. Dans ce cas, on fait appel au mécanisme de MMF (Memory Mapped File) qui fait voir un fichier ou un espace de données comme un vaste tampon en mémoire. Vu du programme, c'est un simple espace mémoire dont la taille peut dépasser la quantité de mémoire physique installée. On le traite comme s'il était tout entier contenu en mémoire physique alors qu'en réalité, il y en a une partie en mémoire et une autre sur le disque (cette partie étant gérée comme le fichier de pagination). L'OS se charge des transferts nécessaires au fur et à mesure des accès réalisés par le programme. Tout ça pour dire que quoi qu'il arrive, ça échange en permanence, en particulier quand des applis comme PS sont actives. D'où l'importance de soigner l'emplacement du fichier de pagination et sa distribution sur différentes partitions. Le laisser tout entier à son emplacement par défaut (le disque système) n'est pas nécessairement une bonne idée.

Ça se gère dans Control Panel | System | Advanced system settings | Advanced | Performance settings | Advanced | Virtual Memory | Change. Désolé, je n'ai pas de version FR sous la main.
Patrick

egtegt²

Tu as raison, mais d'expérience, quand la mémoire ne suffit pas à contenir l'essentiel de la zone de travail, la baisse de performance peut être dramatique (d'un ratio de plusieurs dizaines). Typiquement ça donne des blocages quasi complets pendant parfois plusieurs minutes.

L'espace de pagination sert en fait essentiellement à contenir les fuites de mémoire des différents programmes qui se trouvent inutilisées suite à l'arrêt desdits programmes et peuvent mourir tranquillement dans l'espace de pagination en attendant le prochain reboot.

Pour comparaison, la RAM a des débits de l'ordre d'une dizaine de Go/s et des temps d'accès d'une dizaine de nano secondes, un disque SSD a des débits de quelques centaines de Mo/s et des temps d'accès d'une ms.

C'est presque 100 fois plus rapide en débit et 100 000 fois en termes de temps d'accès.

Les seuls ordinateurs capables de travailler dans des conditions correctes en paginant sont les mainframes, les Unix/linux sont moyens de ce point de vue, et Windows est carrément catastrophique.

ChatOuille

Je ne sais pas si je mêlange tout, mais nous avons d'un coté la pagination de Windows et de l'autre celle de PS (scratch file). Normalement je place la pagination de Windows sur un fichier de taille fixe sur un autre disque. Celle de PS, sur plusieurs disques. Je ne sais pas si je fais bien, mais j'imagine que lorsque PS va demander plus de mémoire, il va gérer les scratch files selon les besoins du moment.

Samoreen

Citation de: ChatOuille le Décembre 03, 2019, 18:05:01
Je ne sais pas si je mélange tout, mais nous avons d'un coté la pagination de Windows et de l'autre celle de PS (scratch file). Normalement je place la pagination de Windows sur un fichier de taille fixe sur un autre disque. Celle de PS, sur plusieurs disques. Je ne sais pas si je fais bien, mais j'imagine que lorsque PS va demander plus de mémoire, il va gérer les scratch files selon les besoins du moment.

C'est une bonne remarque. Bien qu'il n'y ait pas d'informations extrêmement précises sur ce que contiennent les scratch files de PS, il semble bien que ceux-ci stockent une grande quantité de données. Si PS utilise uniquement ces fichiers pour gérer ses besoins en mémoire (ce qui voudrait dire qu'il a son propre système de gestion de mémoire virtuelle), je considère ça comme une erreur parce qu'un gestionnaire de mémoire virtuelle géré par une application ne sera jamais aussi performant qu'un MMF dont j'ai parlé plus haut. Si c'est le cas, ce choix est peut-être dicté par un besoin de portabilité. Mais dans ce cas, il aurait mieux valu écrire ce gestionnaire en 2 niveaux : une interface pour l'application et une couche dépendante de la plateforme (MMF pour Windows et mécanisme équivalent - mais largement ignoré en général - pour tout ce qui dérive d'Unix/Linux).

Je me suis posé la question de savoir si les fichiers scratch étaient en fait des MMF. J'ai vérifié et a priori, la réponse est non. Ce sont des fichiers "normaux".

Cela fait probablement partie des choix qu'il aurait fallu faire dès le départ. Comme cela arrive souvent, l'adaptation des logiciels à l'évolution des OS est toujours freinée pour les mêmes raisons : paresse des développeurs/designers, manque de ressources (argument non valide chez Adobe), manque de motivation tant que le business fonctionne,...

Tout ceci n'est que mon humble avis. Je ne parle que par expérience.
Patrick

psbez

Je sais, depuis assez longtemps, que je dois passer à 8 Go sur ce "vieux" PC Mais tout marchait impec avec Windows 7. J'aurais dû me méfier quand j'ai réussi à installer W10... Si j'avais su, je serai resté sur W7.. Mais c'est OK je vais mettre une barrette de +. Merci à tous pour vos très intéressants commentaires.

egtegt²

Citation de: Samoreen le Décembre 03, 2019, 18:37:47
C'est une bonne remarque. Bien qu'il n'y ait pas d'informations extrêmement précises sur ce que contiennent les scratch files de PS, il semble bien que ceux-ci stockent une grande quantité de données. Si PS utilise uniquement ces fichiers pour gérer ses besoins en mémoire (ce qui voudrait dire qu'il a son propre système de gestion de mémoire virtuelle), je considère ça comme une erreur parce qu'un gestionnaire de mémoire virtuelle géré par une application ne sera jamais aussi performant qu'un MMF dont j'ai parlé plus haut. Si c'est le cas, ce choix est peut-être dicté par un besoin de portabilité. Mais dans ce cas, il aurait mieux valu écrire ce gestionnaire en 2 niveaux : une interface pour l'application et une couche dépendante de la plateforme (MMF pour Windows et mécanisme équivalent - mais largement ignoré en général - pour tout ce qui dérive d'Unix/Linux).

Je me suis posé la question de savoir si les fichiers scratch étaient en fait des MMF. J'ai vérifié et a priori, la réponse est non. Ce sont des fichiers "normaux".

Cela fait probablement partie des choix qu'il aurait fallu faire dès le départ. Comme cela arrive souvent, l'adaptation des logiciels à l'évolution des OS est toujours freinée pour les mêmes raisons : paresse des développeurs/designers, manque de ressources (argument non valide chez Adobe), manque de motivation tant que le business fonctionne,...

Tout ceci n'est que mon humble avis. Je ne parle que par expérience.
En fait, pour moi c'est exactement l'inverse : quand le système fait la pagination, il le fait avec des algorithmes qui ne savent pas ce que contiennent les pages mémoire qu'il pagine, le logiciel lui sait à quoi servent les espaces mémoire qu'il utilise donc il peut optimiser ce qu'il met de côté.

Samoreen

Citation de: egtegt² le Décembre 06, 2019, 14:39:33
En fait, pour moi c'est exactement l'inverse : quand le système fait la pagination, il le fait avec des algorithmes qui ne savent pas ce que contiennent les pages mémoire qu'il pagine, le logiciel lui sait à quoi servent les espaces mémoire qu'il utilise donc il peut optimiser ce qu'il met de côté.

Ce n'est heureusement pas aussi binaire que ça. C'est plutôt ternaire d'ailleurs. Il n'y a pas d'une part l'état en mémoire physique et d'autre part l'état sur le disque. Il y a un état intermédiaire géré au travers de ce que l'on appelle les working sets et qui grâce à des algorithmes très sophistiqués permet de mettre en réserve (juste avant de les paginer) des zones mémoire dont l'application pourrait avoir besoin dans un avenir proche. Ce sont des algorithmes assez proches dans leur philosophie de ceux utilisés par le "garbage collector" du framework Microsoft .Net. Et au final, ça fonctionne très bien et à un niveau système plus performant que les applications n'ont pas la permission d'utiliser.
Patrick