AC 2020 dead slow

[Emil]

Like many other user reported my AC Pro 2020 became very slow after converting my db with 280,000 catalogued items.



All tests above have been done with a 20kB JPEG file located on my SSD.
As you can see, switching modes takes lots of time; each vertical line of the grid shows 10 seconds!

After some fiddling with Process Hacker, Process monitor and a script, I found that 10,000 AC-keywords would add a latency of over one minute! My db just contains 4,800 old AC-Keywords.

I decided to replace keyword.dbf and keyword.cdx with copies from a fresh and empty db. Here's the results with exactly the same commands as used in the screen shot above:



As you can see, all timings are way better then before, however there are no AC-keywords any more: The master keywords list is empty, the items don't show any AC-keywords, search won't find any AC-keywords . . .

But what do I loose? I've started using IPTC-Keywords many years ago and all these old AC-Keywords were just lugged for many years.

Why does AC 2020 need to read all AC-keywords from the db each time when switching to another mode?


BTW. Here's a screen shot of my good old AC Pro 8, same db, same actions and with all old AC-Keywords:

[Janto]

Hi Emil, thanks a lot for your investigations! I am experiencing a similar performance hit with Ultimate 2019, and your workaround of throwing away the ACDSee keywords made the performance a lot better, even tho not perfect. But at least, it's usable for me now. I'd say it went from 20s for switching to View mode to about 2s, plus a lot of lag switching between "Metadata" and "Organizer" tabs in the Properties pane or when switching folders.

My workflow was to add ACDSee keywords to the images, and then apply a metadata preset which copied the ACDSee keywords to the IPTC keyword list before uploading the photos to my sites. It's much better to directly use the IPTC keywords, so I updated my workflows as soon as I discovered your workaround indeed works. Thanks again, this probably saved me 30s per image!

[Emil]

I wonder why no one from ACDSystems ever dropped in here, but I'm sure they've observed the issue and we will see a better performance with the next build. Imho, as is v13 isn't usable at all.

[MBangert]

I am shure that they have no solution. They have also no solution for my Problem with the "Crash depending on size of the database".

[GusPanella]

I would happily give up a year's worth of new editing feature and return exposure stacking, focus stacking, and facial recognition for a stronger DAM and database backend. But alas, I am probably in the extreme minority.

[MBangert]

A functional, stable and fast Version is more helpfull than new Features !

What should I do with new Features if the Programm crashes with more than 15.000 of my Pictures since the 2019 Version ?

Ultimate 2018 can handle this number of Pictures and many many more without any Problem.

[Emil]

I like your thinking too Gus :-)

I would happily give up a year's worth of new editing feature and return exposure stacking, focus stacking, and facial recognition for a stronger DAM and database backend. But alas, I am probably in the extreme minority.

But that's not something printable on a flyer as it implies that it was wrong before, which imho is not true, it currently just is completely outdated.

[GusPanella]

Agreed. There is not positive marketing in "we changed out back-end, so please give us more money", especially for the majority that probably have less than 40000 images. Better hardware has probably extended the usefulness of the existing builtin database. Users with larger photo-count foot prints don't seem to be the target market. (Even Adobe seems to shy away from that market)

I am waiting for the Artificial Intelligence (AI) tags to appear on the next release as that seems to be the next popular marketing hype of the day. (Albeit, these tools with these claims are certainly not using a full AI engine. Sigh)

I am a bit lucky as Ult2019 works well on my hardware. But the back-end certainly takes more maintenance and seems a bit more fragile than what I would like.

[jtruchon]

Emil Before I trash my current workflow and delete all my ACDSee Keywords. I'm curious, are you using any other db cataloging tools like, categories, labels, or ratings? Is it just the ACDSee keywords that is slowing things down? I think a lot of my keywords could be converted to categories, so before I convert to categories, I wanted to know if a large category set would also cause a slow down.

Thanks

[Emil]

Yes, we do need and actively use categories (precisely 4097 this morning :-), just 1 set of labels, the ratings and the check mark. But we don't need AC:collections, AC:captions, AC:database date, AC:author, AC:remarks and AC:keywords. We also intensively use IPTC meta data.

I didn't even try deleting the categories, it's one of the main features we use all the time, however I try to keep the list small and export older categories to the shortcuts from time to time. This is done with a small tool I wrote several years ago.

Messing up with the DB always is risky and if you do it, it's absolutely on your own risk!. This post was mainly addressed to ACDSystems - apps thrown on the market I discuss in the public.

BTW. Replacing parts of the DB with default DB files works pretty well for us since several years: We have a machine that doesn't do anything else then exporting hundreds of images daily. For this the DB is copied from our master DB without any of the thumb* files. These files are added from an empty DB. We don't need to browse the thumbnails on this machine.
All this wouldn't be necessary if AC could wake up one of the bored cores and bother it with background export jobs :-)

The test was done with the first release of AC Ulti 13 (aka 2020). Since then at least a new German build was released and I currently don't know if this issue got solved.

[mattgod69]

I have massive problems with performance and I don't even really use the database or categories. I mainly use software for organising and batch processing (resizing and renaming) photos for which it is excellent, albeit now much lower than it used to be. I do not really understand what the point of the database is! I am currently trying to optimise and delete everything within the database because I think the problem with performance is linked to this. I do remember a few versions are going to completely clear database to improve things.

[mattgod69]

Looking at my database it is 5.8 Gb in size. I run fast SSD's on all my PCs and I am not convinced there is any need to have thumbnails in the database, although I do stand to be corrected!

[Edvard]

You can delite tumbs.

[Emil]

...I don't even really use the database or categories.

If you want to see how ACs performs w/o a db, got to "File - Database - New" and let AC create to a brand new db, then after a restart, immediately go to "Tools - Database - Settings for excluded folders" (or alike) and exclude all drives you have (e.g. C:\, D:\, ...).

You can't completely disable the creation of a db in AC.

If later you find that you need the db, go back to "Tools - Database - Settings for excluded folders" enable the drives you want to include, and switch back to your old db with "File - Database - Open".

After changing the excluded folders, you might want to go to "Tools - Database - Database optimization", to purge your db.

[mogle]

Good debate. I find it troubling that ACDSee Support is not making any comments on Emil findings. Is their policy just to 'keep quiet' and hope it will go away?

My background is software development and consulting within multi-national companies where I represented top 5 of the largest software providers. Ok, different product price and different consequences if things go wrong. ACDSee could learn something. We would have worked with the customer, in some cases invited them to take part in beta testing. In some cases testing of possible fixes and patches. This can really speed up time-to-fix.