**HORRIFYINGLY SLOW BRIDGE AFTER GETTING M1**

[RIP Bridge Functionality]

hey all!

any ideas or remedies for BRIDGE having an absolute stroke when trying to do incredibly basic tasks like batch renaming 10 WHOLE photo files? i have to force quit after every task. last i spoke with support when i first got this new macbook, they said they basically 'speak different languages' are that they were working on it.

one year later.

curious if anyone had actual advice in the meantime...

truly appreciate your time!

[Justin Other]

Recent Mac Studio upgrade and I'll vouch for the OP. Bridge is unusably slow on this Mac with 64GB RAM and sppedy drives connected directly to the Mac.

Adding a single keyword to 49 files has exceeded 5 minutes and counting as of now. Worst of all, after it completes, it has skipped over some of the selected files and not added the keyword!

This is a big bug for Adobe and a black eye for the Bridge team. Perhaps this app isn't as important as PS or Illustrator or ID, but if you're going to offer it to the market, it ought to be as close to perfect as humanly possible. Sadly, Bridge has collapsed under the weight of an improved CPU and increased memory lol

[Anisha Gupta]

Hi,

Thanks a lot for your feedback.
Please try updating to ACR 14.3 release, that should fix the issue.

Let us know if you still face the same.

Thanks,

Bridge Team

[Justin Other]

@Anisha GuptaIm' sorry to report that updating Camera Raw has no effect on the keyword change times.

The timed test is on 156 JPG files in a single folder, raging from 250 KB to 650 KB. The entire folder is just 66 MB.

With ACR 14.2, I did a Select All on the files and unchecked a single keyword that was previously set for all of them. The time required on a Studio Mac Pro with 64 GB was 00:05:47.

No I've downloaded and installed ACR 14.3. This version doesn't yet appear in the CC app, so I downloaded the installer from the Adobe page and ran it, letting it use all its defaults.

I repeated the timed test. With ACR 14.3 the time was 00:03:26, so a saving of more than 2 minutes (41%). That's certainly an improvement, but waiting 3.5 minutes for 156 small JPGs to update doesn't feel like professional software. By comparison, Photoshop can SAVE AS… on a 150 MB 26 layer file in less than 30 seconds.

Given the number of messages in these forums over the past couple of years that related to the keyword update speed, and given the new Mac hardware and prevelence of SSD, it would be great to see the Bridge team take a hard look at this issue, as it is a true problem for anyone who wants to rely on Bridge and also on keywords.

I can tell you that the issue likely sits in the threading or some hitch with the file system. I watched closely today and sometimes one file of about 450 KB would require 6 seconds to modify, and other times 5 or 6 files of about the same size would modify in the same amount of time. At the end, the final 14 files updated all at once, after about a 3 second delay. Thus it seems reasonable to expect that the bottleneck(s) could be found and addressed.

Let's hope!

[Flexigav]

The only thing that comes to mind for me is that many programs use a dedicated cache of memory as a scratch pad to hold temporary processing data that is released and deleted automatically when finished with. If that resource is limited, data processing is slowed down. Bridge has Cache and 'Media Cache'. While the cache size can be limited and the location can be assigned from the Bridge preferences (Cache Management), the 'Media Cache' is a different story. It's location can't be assigned from within Bridge.

Now I am not sure if one of these caches is dedicated to that scratch pad function, but if it is and it is getting full because it is shared with other file information that accumulates until it is cleaned out, then that might provide a path of investigation. It seems data generated for and used in program processes might be gobbling up valuable resources—a configuration mismatch possibly, that might require a software update solution. I'm sure the M1 chip is not slow, but rather waiting for data caught up in some bottleneck due to the way Bridge is configured on that new technology. This might be a job for the Adobe tech team.

[Justin Other]

@Anisha GuptaI'm providing another repeatable test with more informaiton on the issue. As you get to the bottom of the post, I think you'll find the problem and have a good idea about how the team can investigate it further.

As a reminder: my setup is the 64 GB RAM Mac Studio. The files are on the internal SSD. There are hundreds of gigabytes of free disk space and Bridge can be the only app running. I don't believe that the hardware matters at all. The problem is software-based, as I've detailed below.

Recently I exported 2000 images into a single folder, directly from the Apple Photos app. As opposed to my earlier tests, Bridge handles this directory like a champ. I can change a keyword on all 2000 files and it completes in about 5 seconds. Meanwhile keyword changes on any file in the original, problematic directory of 156 images is always slow as molasses, taking 3–4 seconds for each file.

I moved the slow directory to reside as a sibling for the fast directory. No change in keyword processing speed for either. I moved 10 of the slow JPGs to the fast folder. Now updating the keywords on the 2010 JPGs takes about 40 seconds longer than before.

Here's the latest info that I think the Bridge team will find most interesting: I realized that even though all the 156 slow files also came from the Photos app, unlike the 2000, they were not exported using the "Unmodified Original" option. They were exported after having their color settings edited from within Photos. They also were exported from iCloud, not from the Photos local cache.

So my best guess became that the file data format in an edited version is not the same exact file data format in an unmodified original, when exported from Apple Photos. But it turns out we can prove the difference. Here's how:

An experiment was set up by grabbing 10 photos in the Photos app that were already locally stored, and not sitting on iCloud. I exported them twice. The first time used the Export > Unmodified Originals option, the second was the standard Export > 10 Photos option. These were exported to the same folder, so the name clashes were resolved by the system to append a "1" to the end of the second set of files. No big deal.

Now I opened Bridge and located the new folder with the 20 freshly exported JPGs. I did a Select All and clicked to set a single keyword. Then I quickly switched to the Finder to watch the Date Modified column inside this folder, to see what happens as Bridge processed the keyword edit.

All the unmodified originals update instantly. All the modified JPGs take 3–4 seconds apiece.

This should be enough information to help Adobe investigate and find a final fix for the issue. No doubt the Apple Photos app has been around long enough and has a large enough user population to warrant it.

I can't wait to see what they find and then enjoy being able to use Bridge after they fix it. @Flexigav Thanks for the thoughts. As you can see, it definitely is an issue for the Adobe Bridge engineering team.

[Flexigav]

I am convinced Bridge modifies files through a temporary representation of them in a cache and that is a cause for delays and inconsistencies. When the cache is cleaned out Bridge will reload it again with a new temporary representation of the files being viewed regardless of where the physical files reside. Bridge tends to work with the cached representations rather than the physical files directly... all changes to the cached representations are applied to the physical files in the background. This could be a source of delays! I feel at times the cache of temporary files does not fully represent the actual store of original files until the cache has been cleared and reloaded. After time, differences appear again and the process needs repeating. It appears all this is to speed up the viewing and editing processes by reducing the number of slower hard disk calls, however this might not be so relevant since the evolution of SSD technology, but never-the-less, still used by many applications. This is only food for thought.

[gary_sc]

HI Flexigav,

It's an interesting "food for thought," but it is beyond me how "looking" at a file can change that file. Building a cache is a one-way street. I do not know if this has ever happened to you but I have dyslexia. Occasionally when I glance at some text, I will see one thing but it is not reality — my eyes have jumbled letters to form a different bit of text. Across the many years that this has been going on, looking at something has yet to actually change that thing. When I look at an orange and think apple, it neither turns it into an apple, an apple tasting orange, nor a bad tasting orange (well, it might be that, but that's not my point).

Generating a cache is a one-way process, it's never two-way.

[Flexigav]

Hi Gary_sc,

I have caught Bridge failing to find files that I have been able to find myself searching through folders. The files it found using the Mac 'Find' utility were located in the cache. It did not find the ones directly in folders, even when the search query specifies where to search. When I purge all local cache files then open a folder to view all the image files within, Bridge loads them all back into the cache. Now when I repeat the original search it finds them all. Some times I have to include 'non indexed' files in the search criteria inwhich case I beleive Bridge creates an new index.

I am not sure if Bridge uses the Mac OS file index, or whether it creates its own. I suspect the index might be cached as well. Perhaps these problems result from lack of space to generate a cache of sufficient size for the volume of work undertaken... smaller batches perhaps.

It appears to me that caches must be purged and reloaded now and again. Whatever alterations are done to an image and the file meta data, they are performed on the cached file version. Those updates then propagate through to the original physical file.

Some of these mysterious problems may just result from something in the caching process.

[gary_sc]

HI Flexigav,

One quick question: when doing searches, are you using the best search mode?

A lot of folks completely miss this.

BTW, since you're on a Mac you may want to check out HoudahSpot. I never ever use searching in Bridge because it can't do Boolean searching, HoudahSpot can. It's one of my "MUST HAVE" tools on my Mac.

BTW #2: did you install the newest ACR and did that make a difference in speed? I do not have an M1 computer (it's coming), but from reports I've heard, it solves the speed issue. Did it work for you?

[Flexigav]

I experimented with all of them and in the end I stuck with the 'Advanced Search' feature as it offered a gui that allowed a form of Boolean search criteria creation. In one experiment I had more success when I chose the folder from the system directory tree for the "Look in" field, rather than go with the whole drive. Either way I always had "include all Subfolders" selected. If I didn't do that, on some occassions it seemed to only search the cache and not evey file was loaded in the cache. If Bridge doesn't find all files you requested in your search, your batch selection might not be so comprehensive and you may not realise some files have missed out. All this brings caching into consideration in troubleshooting. Perhaps the process of caching has not been optimised for every system, or systems with lower resources (running out of disk space). I am making more use of 'Collections' now to define temporary batches for meta data or file name modifications instead of just batches created directly from searches. 

[blankframes.com]

I'm having the same issues with Bridge. Generating previews on M1 Max with 32GB of RAM takes AGES and is totaly unusable. I used to fly through my images on 5y old MBP15, but this now has to be fixed since the M1 processors are already 2 years old..

[PECourtejoie · Accepted solution]

Hi, check out the beta version of Bridge that offers native Apple Silicon support: more info on how to get it: https://community.adobe.com/t5/bridge-discussions/the-adobe-bridge-beta-is-now-available/m-p/1312871...

[PECourtejoie]

Hi, Bridge 13.0.1 offers native M1 suppport, you should upgrade to that version, but be informed that while it supports a modern UI with multiple content tabs, it has for the moment lost the multiple windows feature. It might be wise to keep a copy of V12 if you need that feature.