Lenteurs & plantages Lightroom

[Matthieu B.]

Bonjour, rapport à mes propos sur le dossier Lightroom faisant environ 80 Go chez moi, en fouinant je vois que cela concerne essentiellement les Backups (76,4 Go).
Que contient précisément ce dossier ? Les modifications apportés aux fichiers bruts ?
Dois-je tout garder ou y a t-il quelque chose à y faire régulièrement ?

Merci ...

[michel_d]

Il s'agit de copie intégrales du catalogue.
Le sujet vient d'être évoqué sur le forum. Voir ici

Par ailleurs il est totalement inutile de faire des sauvegardes sur le même disque que celui qui porte le dossier catalogue, car en cas de crash on perd tout. Les sauvegardes doivent impérativement être faites sur un disque différent.

[Matthieu B.]

Oui, je les fais sur disque dur externe.

[michel_d]

Il ne suffit pas de les faire sur un  disque externe, il faut que ce soit un disque différent de celui sur lequel se trouve ton catalogue courant. Or d'après ce que tu a écrit plus haut il semble bien que les sauvegardes se trouvent dans le dossier du catalogue et donc sur le même disque.

[Matthieu B.]

Mon catalogue courant se trouve sur le DD de mon ordinateur portable, et est régulièrement sauvé sur DD Externe par précaution.
De même que l'ensemble du dossier Lightroom et tout ce qu'il contient.

[michel_d]

OK; je comprends.
Dans ce cas il y une redondance entre la copie que tu fais toi-même du catalogue sur le disque externe et les sauvegardes faites par LR. Mais dans ce domaine "trop fort n'a jamais manqué"

[Cyril]

Bonjour les amis,

Tout a été dit et je n'ai que peu de chose a rajouter.

Effectivement l'architecture I5 ou I7 est plus adaptée pour travailler confortablement dans le module développement.

Sauf qu'il y a une fausse idée, celle de croire qu'un processeur avec plus de cœurs est un processeur plus performant. La performance ne se caractérise pas en nombre de cœur mais en MIPS (millions d'instructions par seconde).
Augmenter le MIPS  c'est
----augmenter le nombre de cœur et/ou la fréquence (encore une fausse idée reçue de l'époque où on martelait que plus la fréquence était élevée, plus le proc allait vite)
----Modifier l'architecture (jeu d'instruction, bus de donnée interne, niveau de cache L1, L2 et L3
-----Et d'autres paramètres plus techniques comme la longueur/parallélisation des pipelines (dont dépend l'UAL: Unité de calcul Arithmétique et logique ).
-----Optimiser le langage de niveau supérieur (Opérating Système) et travailler via un interpréteur ou assembleur

Exemple concret:
Android tourne moins vite sur un quadcore que windows mobile sur un dualcore (couche OS mieux optimisée et moins lourde)

Mon post n'apportera pas d'intérêt dans le problème soulevé, mais j'avais envie d'y mettre mon grain de sel.

[Matthieu B.]

Tout grain de sel qui assaisonnera mon plat comme il faut est le bienvenu !