LR: Gestion de la mémoire et gestion des erreurs, performances, etc.

[kaf]

Hier je suis tombé sur un problème de gestion mémoire, et de gestion des erreurs, dans LR.

J'ai fait une mise à jour des IPTC sur plus ou moins 30000 images, et LR n'a pas apprécié du tout. Invariablement, l'opération s'est terminée par un "erreur système: not enough memory" laissant le processus de LR dans un état de mort apparente. Obligé de le tuer via le task manager. Résultat, une base de donnée corrompue, qu'heureusement LR a pu récupérer. La seule solution que j'ai trouvée a été de scinder la mise à jour en 2x 15000 images, et là, tout s'est bien passé.

Même si la mise à jour de la base de donnée plante, ce qui est en soi déjà malheureux, je trouve dommage que LR ne puisse pas retomber sur ses pieds proprement.

De plus, cette mise à jour des IPTC m'a aussi fait mettre le doigt sur un problème de performance. J'utilise beaucoup de collections dynamiques, et certaines de ces collections utilisent dans leurs critères précisément les champs IPTC que j'étais en train de mettre à jour. Une fois la mise à jour des IPTC terminée, la réévaluation par LR des collections dynamiques a été atrocement lente (plus d'une heure!).

Au final, ça a marché évidemment, mais j'ai du mal à comprendre pourquoi cette opération a été aussi longue.

En bref, pour l'instant je ne dispose que d'un "vieux" PC (Core2Quad 3GHz, 4Gb de mémoire et OS 32 bits). D'ici fin de semaine je devrais recevoir ma nouvelle machine qui, je l'espère, me mettra à l’abri de ce genre de déboire pour quelques temps (i7, 16Gb de mémoire et OS 64 bits). Mais néanmoins, est-ce que quelqu'un aurait déjà rencontré ce genre de problème et aurait trouvé une stratégie de mise à jour pour ne pas faire planter LR?

[THG]

Oui, scinder le travail en plusieurs étapes, surtout sur des machines poussives.

[Migall]

Core2Quad 3GHz -> Pas si poussif que ça, loin de là

[THG]

Core2Quad 3GHz -> Pas si poussif que ça, loin de là

Ben aux standards actuels, si ça commence à devenir poussif, surtout si l'environnement (RAM, système d'exploitation) est du même accabit.

Traiter des métadonnées par lots, sur des dizaines de milliers d'images, prend du temps et exige des ressources hard assez solides, j'en veux pour preuve ce qui t'est arrivé.

Et je te rassure, tu n'es pas le seul, je connais des types qui ont des anciens MacPro qu'ils pensaient indéboulonnables sur du long terme, et qui rament aussi dans ce genre de tâches.

[kaf]

Ben aux standards actuels, si ça commence à devenir poussif, surtout si l'environnement (RAM, système d'exploitation) est du même accabit.

C'est exactement pour ça que je change, même si la machine n'est pas poussive dans un usage "normal", depuis le 5DII ça devient vraiment limite dans CS5. La principale limitation venant évidemment de la mémoire, 4Gb ça devient peu...

Par contre, j'ai du mal à comprendre ce qui justifie ces problèmes de mémoire. Une mise à jours de 30000 tuples dans une BD relationnelle, ce n'est vraiment pas énorme et ça ne devrait pas faire planter le processus. De plus, si la mise à jour est effectuée au sein d'une transaction, je ne comprends pas pourquoi un plantage laisse ma BD dans un état incohérent. En principe, si la BD est ACID, ça ne devrait pas arriver

Et je ne m'explique pas non plus les problèmes de performances lors de la réévaluation des collections dynamiques (qui ne sont jamais que des vues le langage SGBD). Les critères ne sont pas très complexes, et le nombre de tuples dans la base n'est pas indécent, normalement ça devrait être presque instantané. Par contre, j'ai eu l'impression qu'il y avant une interférence entre la réévaluation des collections dynamique et l'affichage, celle-ci me semblait sensiblement plus rapide (mais tout de même très lente), en positionnant l'affichage sur une collection vide. Étrange...

Enfin bref, j'espère que ma nouvelle machine me mettra à l'abri de déboires de ce type pour quelque temps, mais je pense que des progrès pourraient être faits du côté de LR

[Pat91]

C'est exactement pour ça que je change, même si la machine n'est pas poussive dans un usage "normal", depuis le 5DII ça devient vraiment limite dans CS5.

Je ne discute pas pour les jobs en batch avec déclenchement de threads multiples, etc. Mais pour le traitement d'une image dans CS5 même avec le volume produit par un 5D MKII, la mémoire physique de ma machine (XP Pro SP3 + 3GB) n'est jamais utilisée complètement (à condition qu'il n'y ait pas d'autres applis lourdes en train de tourner - par exemple quand CS5 a été lancé depuis Lightroom, et encore).

Rappelons qu'Adobe a publiquement admis que les problèmes de performances de LR3 ne sont pas, pour la plus grande part, liés à une configuration hardware trop faible (à condition de ne pas utiliser une machine vieille de 10 ans).

En principe, si la BD est ACID, ça ne devrait pas arriver

Elle ne l'est pas tout à fait ("mostly ACID compliant", ce qui veut tout dire et rien dire). J'ai déjà exprimé ici mon étonnement concernant le choix de SQLite par Adobe (et par Bibble Labs). Pour Windows, le choix du moteur MS SQL Express aurait été de loin préférable (et pas plus cher : gratuit) ou, pour une solution plus portable, BTrieve/Pervasive (un peu plus coûteuse en royalties). Je ne suis pas sûr que l'économie réalisée n'ait pas été compensée par les frais générés par des problèmes de maintenance accrus.

[kaf]

Je ne discute pas pour les jobs en batch avec déclenchement de threads multiples, etc. Mais pour le traitement d'une image dans CS5 même avec le volume produit par un 5D MKII, la mémoire physique de ma machine (XP Pro SP3 + 3GB) n'est jamais utilisée complètement (à condition qu'il n'y ait pas d'autres applis lourdes en train de tourner - par exemple quand CS5 a été lancé depuis Lightroom, et encore).

C'est que tu n'utilises pas, ou peu, d'objets dynamiques. J'ai régulièrement des TIFF 16 bits entre 1 et 2 Gb une fois compressés et sauvés sur disque. En mémoire c'est donc encore un peu plus élevé. En 32 bits avec 4Gb de mémoire, on est vite au taquet.

[THG]

Quand je parle de "poussive", c'est juste une manière de parler, of course.

Quant à Adobe, oui, ils ont encore du boulot d'optimisation à faire, c'est clair.

[kaf]

Quand je parle de "poussive", c'est juste une manière de parler, of course.

Quant à Adobe, oui, ils ont encore du boulot d'optimisation à faire, c'est clair.

J'avais bien compris

[Pat91]

C'est que tu n'utilises pas, ou peu, d'objets dynamiques. J'ai régulièrement des TIFF 16 bits entre 1 et 2 Gb une fois compressés

Je dois dire que je suis déjà effrayé quand j'ai des TIFF de 200-300 MB générés à partir de mes malheureux 15-20 MB de RAW. Mais effectivement, avec des TIFF à 1 ou 2 GB, le 32-bit est hors compétition.

Je suis bien convaincu que le 64-bit est la seule solution à terme en photo. Même si un changement de machine n'est pas toujours nécessaire selon les cas, reste le problème du support du hardware existant. Je veux bien dépenser quelque argent pour une nouvelle UC mais je ne suis pas trop chaud pour remplacer des périphériques qui fonctionnent encore bien et qui ne sont pas supportés en 64-bit (et qui ne le seront sans doute jamais).