Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Update (10.1.2) is very slow

Alessandro Guida
Hi,

I've just updated C1 this afternoon with 10.1.2 version and I find it very slow...do you have the same problem?

Ale
0

Comments

18 comments

Date Votes
  • Luke Miller
    I just updated to 10.1.2 yesterday and it runs fine for me.
    0
  • Richard Allen
    Same problem here

    I have reported it via a ticket to support.

    Would be good if you did the same so they have more data to work with.

    Richard
    0
  • Alessandro Guida
    [quote="Richard_Allen" wrote:

    Would be good if you did the same so they have more data to work with.
    Richard


    I will, thanks!

    Alessandro
    0
  • NN635623013469669720UL
    It's the same problem to me.
    That's really annoying to wait seconds when you select something. Is there a bugfix?
    Greetings, Arno
    0
  • Phil Thornton
    I too have noticed v 10.1.2.23 (aeba4c7) to be extremely slow and unresponsive.

    It doesn't seem to be using the "preview" cache at all, but appears to always convert from raw - at least, the image starts life "fuzzy" than after a second or so, shows in clear detail.

    I am running windows 10 on a 6 processor Xeon 3+GHz CPU, with 32GB RAM, Catalogue on SSD, Images on spinning disk mirror storage space. Two top of the range nVidia cards, Dell screens (browser on one, working image on the other). Canon 5DS, so fairly large raw files.

    Clicking on two or three images in sequence send the CPU usage to 100% on all processors, and working set RAM climbs fairly quickly.

    Have we been given a debug version?

    Running with video card hardware assist off seems to make it a bit slower, but uses less RAM (purely by seat-of-the-pants estimation).

    I am available for testing.
    0
  • Robert Whetton
    i5 2500K with AMD R9 390. Session on RAID 0 SSD - Images on solo SSD - testing C1 V10.1.23 everything feels faster than V9, from making changes (instant changes) to processing final image (3 sec for high ISO4000 images from 7D2)..
    0
  • Alessandro Guida
    I sent a ticket to the support but I didn't get an answer yet.

    I had to downgrade to 10.1.1 and it seems to work...so probably we have to wait for some patch I think ☹️
    0
  • Phil Thornton
    I have just noticed that if I browse to my images via the actual folder where the images live, rather than from an "album" such as recent imports or whatever, then the performance is fine. It's still annoying, but one can at least work around it.
    0
  • Permanently deleted user
    [quote="Phil121" wrote:
    I have just noticed that if I browse to my images via the actual folder where the images live, rather than from an "album" such as recent imports or whatever, then the performance is fine. It's still annoying, but one can at least work around it.


    Now that you point that out, I realise that every time I click in an album it reindexes the whole thing!
    0
  • SFA
    [quote="gusferlizi" wrote:
    [quote="Phil121" wrote:
    I have just noticed that if I browse to my images via the actual folder where the images live, rather than from an "album" such as recent imports or whatever, then the performance is fine. It's still annoying, but one can at least work around it.


    Now that you point that out, I realise that every time I click in an album it reindexes the whole thing!


    Album or Smart Album?
    0
  • Alessandro Guida
    Try creating a backup of that catalog, and check off Optimize Catalog. This should clear up any lingering issues due to unused indexes in the catalog database.


    This is what the support told me to do. But after that I still have problems....and downgrade again ☹️
    0
  • Permanently deleted user
    [quote="SFA" wrote:
    [quote="gusferlizi" wrote:
    [quote="Phil121" wrote:
    I have just noticed that if I browse to my images via the actual folder where the images live, rather than from an "album" such as recent imports or whatever, then the performance is fine. It's still annoying, but one can at least work around it.


    Now that you point that out, I realise that every time I click in an album it reindexes the whole thing!


    Album or Smart Album?


    Smart only apparently.
    0
  • SFA
    [quote="gusferlizi" wrote:


    Smart only apparently.


    In that case that is what I would expect since it will be updating in real time (or very near real time) if doing its job.

    The application is trying to make some guesses about how you are likely to be working in order to make the process faster BUT of course it is limited in terms of how far it can second guess what you are about to do next.

    The first time you open a Smart Album while you are working in the system and have not used it recently (and likely always after re-starting C1) the chances are that it will take some time to go and check whether anything has been added or removed from your folders ... or in effect the simplest thing is just to re-run the selection process and build a new "in memory" list of images and sort them as currently specified. Maybe also re-process depending on the current state of the preview files (default size compared to screen, perhaps Proof Profile setting, etc.)

    Potentially quite a lot of processing to do once it has found a file that fits the Smart selection test.

    It might be useful to discuss whether there are specific ways of working with the system that would make sense for some preferred workflows. For example would Hibernation rather than shut down be better if you expect to go back into the same Album the next time you switch the computer on? That sort of thing.


    Grant
    0
  • Phil Thornton
    I have just added this information to the case I opened with support:

    "Further information.

    I have discovered that CO is writing the xmp sidecar file all the time. I opened the all images collection and watched the windows resource monitor. I noticed that the system task suddenly started writing to the xmp files. I used the windows file browser to check on the details of a random xmp file and, sure enough, the date modified had been changed to today, "just now". So I saved that in a separate folder and restored that particular xmp file from last night's backup (Acronis) and the date modified was dated a couple of days earlier on the restored file - probably from the last time I opened the all images collection. I compared the contents of the two files (using windiff from the ms SDK), and they are completely identical."

    I don't know if that is a new behaviour with this version. I haven't downgraded yet, in the hopes of a fix fairly soon.
    0
  • Richard Allen
    Phil,
    Have you informed technical support of your findings as it might help them to help us?

    Regards,
    Richard
    0
  • Phil Thornton
    Oh yes!

    I'm a long-time computer programmer, and I know how these things can happen. And that all information is good, but there needs to be a liberal application of pinches of salt.

    So, if I notice what I consider to be an aberrant behaviour, I report via software ticket. Haven't had a response in the past couple of days. I trust they don't think I'm crying 'wolf' - but lagginess is a hard one to track down because of the sheer number of variations in the circumstances, and the differing tolerance we each have to delay. So it will probably take some time to pinpoint the root cause.
    0
  • SFA
    [quote="Phil121" wrote:
    I have just added this information to the case I opened with support:

    "Further information.

    I have discovered that CO is writing the xmp sidecar file all the time. I opened the all images collection and watched the windows resource monitor. I noticed that the system task suddenly started writing to the xmp files. I used the windows file browser to check on the details of a random xmp file and, sure enough, the date modified had been changed to today, "just now". So I saved that in a separate folder and restored that particular xmp file from last night's backup (Acronis) and the date modified was dated a couple of days earlier on the restored file - probably from the last time I opened the all images collection. I compared the contents of the two files (using windiff from the ms SDK), and they are completely identical."

    I don't know if that is a new behaviour with this version. I haven't downgraded yet, in the hopes of a fix fairly soon.


    When this has come up before the advice has been to change the default Sync settings.

    I don't have any inter-application XMP synch requirements so for me Sync is turned off so I have no practical experience. Try a search and you should come up with one or two threads in the past 2 or 3 months that may provide useful information. Meanwhile check how your preferences are set.

    HTH.


    Grant
    0
  • Phil Thornton
    Yes, after setting the auto sync xmp files to none, performance is now good. I have checked experimentally, and there is no observable change of behaviour between 10.0 and 10.1.2, so the fact that I noticed the poor performance just after installing 10.1.2 is a red herring. I did just spend $1500 on a posh video card to enhance performance, so perhaps I was being a bit sensitive.

    I shall open another thread to explain what I think is wrong with the implementation of the sync metadata system.

    Thanks for all the suggestions.
    0

Post is closed for comments.