Bridge: Poor performance with large folders

  • 2
  • Problem
  • Updated 1 year ago
  • (Edited)
I use Bridge at work for image processing and cataloging. I have two workstations with local image storage (one primary for processing, the other for tethered capture) and a server for storage. Our network is Gig Ethernet, 10Gig to the server, all Windows 7. I have decently fast i7 PCs with 8 and 16GB of RAM. Fully updated Bridge CC.

Frequently, I need to find and work with saved images in larger folders (up to 6-7000 images currently) and/or nested folders. Most are JPEG files although I have smaller numbers of active PSD's as well.

Listing these folders, even on the internal hard drive, takes forever. I understand that thumbnails and metadata are read but several minutes before I can work with anything is ridiculous.

Searching via the upper right-hand corner search field almost always returns a not found result unless I've already waited for the folder to fully load. Finding images in subfolders often never works. Even after Bridge builds an index, the next search has the same problem. Using the full search tool and selecting non-indexed files works but again is terribly slow.

In contrast, I load files via ftp to a remote server using Cyberduck. I get a listing of 6000+ files in about 20 seconds. Windows Explorer only takes a few seconds to load a folder of that size, local or remote.

Is there ANY way to make Bridge do a simple file listing more quickly, and for search to actually work? I'm fine with waiting on metadata and thumbnails but its gotten to where Bridge is almost unusable.

Lightroom is not a solution, since its missing all the connections for batch processing via Photoshop.
Photo of David Converse

David Converse

  • 555 Posts
  • 168 Reply Likes

Posted 3 years ago

  • 2
Photo of David Converse

David Converse

  • 555 Posts
  • 168 Reply Likes
I should add that even listing smaller folders is much slower than it should be. And I use two Macs at home, I see the same issue although I'm not storing as many files in any one folder.

Things like preferring embedded previews, storing 100% preview in cache, automatically export cache, etc haven't made much of a difference, unfortunately. I have the cache storage settings at 500,000.
Photo of Stanisław Siedlecki

Stanisław Siedlecki

  • 1 Post
  • 0 Reply Likes
I have [almost] same problem too. When opening a new folder, it's okay, it has to make previews and so on, I can wait a moment. But then it turns out that Bridge doesn't make previews for all files inside folder, but only for some part of it [I have "prefer embedded" turned on], and after a few scrolls it lags terribly [and that's on i7-4770k, 16gb of ram and SSDs]. Funny thing is that Bridge CS6 didn't have that problem.
Photo of David Converse

David Converse

  • 555 Posts
  • 168 Reply Likes
Any ideas? Things have just gotten worse. I have larger folders now, over 9000 JPEGs. There are frequent "Not Responding" timeouts of a minute or two, lots and lots of lag, terrible performance. Bridge is by far the slowest program on the computer.

Windows Explorer and Faststone can list a folder in a few seconds. Even over ftp, to a remote server, both Cyberduck and cURL can list a 9000 image directory in a few seconds.

With Bridge, it takes several minutes to even list a local folder. Delete or rename a file and the ENTIRE folder listing rebuilds, again taking several minutes. I frequently have to switch back and forth between folders and its painful to say the least.

I've deleted and rebuilt caches and tried every permutation of cache settings with no luck. Disabled unneeded startup scripts, I have no third-party plugins other than Image Processor Pro.

Right now I'm looking for alternative software because Bridge is about useless from being so slow. But its a hard sell to my management, Photo Mechanic is $150 and I still need access to ACR and scripting for Photoshop and metadata processing.
Photo of David Converse

David Converse

  • 555 Posts
  • 168 Reply Likes
Are there any plans for a rewrite of Bridge to fix these performance issues?

tl;dr- Bridge is WAY slower than other image viewer software, by a factor of 15-100x.

I just tested Bridge CC 2018, Faststone Image Viewer 6.3, Irfanview Thumbnail Viewer 4.5, and Windows Photo Gallery 2012. Windows 10 Pro, Gigabit Ethernet network to a server on our LAN. Everything AFAIK at the most recent versions.

Display test was a folder containing 10,278 1000px JPEG files. About 3.29GB of image data total.

Windows Photo Gallery and Faststone Viewer both display all files and metadata (Photo Gallery shows pretty much all IPTC and EXIF data) in about 5 seconds. Irfanview took about 15 seconds to fully load all thumbnails. All using similar (tile) views.

Meanwhile, Bridge CC takes over 4 minutes to load the folder. This is with existing caches, and no changes to the folder since the last time it was displayed. The file list builds serially, so the last files aren't visible until everything is loaded. Search also doesn't find files until the folder loads.

Loading a folder on the internal hard drive has about the same comparative performance.

I've also done testing with Cyberduck and cURL to an ftp server on the Internet and both will retrieve a folder list (same set of JPEGs) in just a few seconds.

Another PC running Windows 7 (better spec'd hardware) has similar performance.

Frankly, this is ridiculous.
Photo of Cristen Gillespie

Cristen Gillespie

  • 1539 Posts
  • 474 Reply Likes
> Are there any plans for a rewrite of Bridge to fix these performance issues?>

My fingers are certainly crossed that Bridge will undergo a substantial rewrite. I need it for Stacks to stay organized or I'd be looking elsewhere. Being on a Mac, I haven't found a lot of options. Bridge needs to preview more types of files, especially Adobe's own files — needs to rework the interface so we don't need to keep multiple instances of Bridge open simply to drag and drop when performing simple file organization, needs to up its game adding keywords (slower than molasses adding them to a folder of large files—not even a large folder), and definitely needs to speed up when it comes to opening folders with a lot of files, even when the individual files are small and simple to preview, unlike my PSD files. I have thought if perhaps they would increase the file limit for cache, or better still, let the user determine the max size for cache like many other apps do, it would help. One large folder eats up a lot of the files held in cache, so it doesn't take very long for cache to scroll away.

That's not the complete answer to cache taking so long to show up, but it might be one part of it. Maybe we need to have other, better trade-offs, speed vs quality, than we have at present, so we can get past whatever it is that has it running so slow. I have also noticed that if I open a folder and quickly decide nope, wrong folder, and move to another, Bridge throws a hissy fit. It really wants to finish caching the folder I opened before it will let me look at yet another one. All of these little things  bringing Bridge to its knees make me agree with you that a rewrite is probably the only way out of this.

Unfortunately, I need more features than the Finder (or anything else I've found) offers, so Bridge it still is. At least it can perform most of the basic chores, so long as I have the patience to wait for it.  '-}