Auto Sync sidecar XMP is poisonous to performance
There are 3 options available in the preferences Image tab for sidecar syncing. The default is "None" and changing that will have a deleterious effect on performance.
I had naively assumed that "sync" meant "If there's a sidecar file, make sure the information it it matches the catalog, and if there is no sidecar file but information in the catalog that should be in one, then create it".
What it actually means is "every time you open a selection of images, create a sidecar file for every image, regardless of whether there was one before, and regardless of whether one is necessary".
This will slow down performance quite dramatically. There is a finite number of files that can be open at any one time, and writing hundreds of small files on a spinning disk will very soon cause the machine to grind to what seems a halt. Even once it has finished writing all those unnecessary xmp files, performance will still be slower than it ought - because any operation that involves processing a raw file or searching or analysing keywords etc will cause the wretched things to be read again if you have this setting moved from the default "none".
In the old days, when bashing our collective heads against IBM's design team, we had a phrase for a situation like this: "broken as designed". Perhaps the good people at Phase One will do something about this interesting design, but I won't be holding my breath.
I really would like the documentation to be a bit more fullsome, however, and I think that ought to be done. At the very least, there should be a warning that the performance hit will not be minor, but in the realm of making the catalogue system essentially unuseable for any more than a very few images.
Onwards.
Phil
I had naively assumed that "sync" meant "If there's a sidecar file, make sure the information it it matches the catalog, and if there is no sidecar file but information in the catalog that should be in one, then create it".
What it actually means is "every time you open a selection of images, create a sidecar file for every image, regardless of whether there was one before, and regardless of whether one is necessary".
This will slow down performance quite dramatically. There is a finite number of files that can be open at any one time, and writing hundreds of small files on a spinning disk will very soon cause the machine to grind to what seems a halt. Even once it has finished writing all those unnecessary xmp files, performance will still be slower than it ought - because any operation that involves processing a raw file or searching or analysing keywords etc will cause the wretched things to be read again if you have this setting moved from the default "none".
In the old days, when bashing our collective heads against IBM's design team, we had a phrase for a situation like this: "broken as designed". Perhaps the good people at Phase One will do something about this interesting design, but I won't be holding my breath.
I really would like the documentation to be a bit more fullsome, however, and I think that ought to be done. At the very least, there should be a warning that the performance hit will not be minor, but in the realm of making the catalogue system essentially unuseable for any more than a very few images.
Onwards.
Phil
0
-
Phil,
I think you need to put this in a Support Case - it's the way Phase manage Enhancement Requests as well as evident problems - and include you thinking about how the need (or lack of need) for XMP files could be better defined.
I would have thought for most people, the need for managing metadata for a single in multiple applications is rarely a long term continuing process for large number of files once processed to a point of output. Occasionally some metadata might need to be updated between systems I suppose but that could be handled either as an "on demand" action or though some sort of scheduled batch update. Or a combination of the two.
The challenge is that for some people having all of this happening in the background without any real thought be applied on their part may be more important than their perceived performance concerns if they have any.
One option might be to make the process available for real time "must have it now I really, really need it" operation or allow it to run in the background having been made aware that, should it be important for some reason, the Sync check may not be complete for the image being viewed.
But whatever the most complete solution may be for those who need it the best option to address any design change is via a Support Case.
That said a discussion on the forum has the potential for identifying a number of different preferred approaches for the designers to consider. Maybe we could take some guesses as to how many different approaches are proposed!
Grant0
投稿コメントは受け付けていません。
コメント
1件のコメント