Bridge: Speeding Bridge Thumbnails

  • 1
  • Idea
  • Updated 2 years ago
  • (Edited)
Bridge already has 3 ways to speed up the thumbnail embedding and reading - but it's still painfully slow in folders of hundreds of .tif files for ex.
There should be a 4th way of thumbs handling - found in some Slideshow viewers

It should read just once the content of a folder and take a "Snapshot" of the thumbs as found at that moment. Then will only add more thumbs if it's asked to Update.
It should not update automatically!
Especially for Archived folders - that don't change their contents for years - it would be a blessing. As of now Bridge keeps reading all the files every time - instead it could just read the Snapshot of the folder -
A simple function "Update Thumbnails" would complete this feature by prompting Bridge to load all new stuff (or remove) and update the existing "Snapshot"!
Of course, what I call Snapshot would be an expert file saved with the folder - but not a cache as it is now. More like a high res photo file of the folder contents.

The increase in speed could be tremendous - and it would fit the needs of the users who frequently need to check old series of files very quickly.

Best Regards
pabloantoine
Photo of pablo antoine

pablo antoine

  • 10 Posts
  • 0 Reply Likes

Posted 7 years ago

  • 1
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 766 Reply Likes
Bridge keeps a database of thumbnails/previews. Unless you wipe out the database, the files it's already thumbnailed will come up instantly.

So it sounds like something may be wrong with your configuration of Bridge, or your system.
Photo of pablo antoine

pablo antoine

  • 10 Posts
  • 0 Reply Likes
Yes, it comes instantly - but the program will automatically try to check the contents of the folder without being asked. This will permanently slow down the quick browsing of folders with many large files.
In any option now Bridge will stop momentarily - even for many seconds, preventing you to do a quick browsing.
Try to drag the cursor down quickly through a folder with hundreds of .tif files- see what happens. It stops to load or read or whatever it does - it gets stuck for long seconds, then skips many rows of thumbs...
This behavior is common in many graphic browsers (even my Nikon View NX2 has it) - but solved by others (My Album for ex) with the option to update folders only when prompted.

I use a Mac 2.8 GHz Quadcore with OS 10.6, 8 GB RAM - and the folders are on drives separated from the system one - so it's not my system slow.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 764 Reply Likes
Bridge will check to see if the files have been modified. That's normally very quick. If you see it hanging for several seconds, then something else is wrong (like a bad file server, slow net connection, corrupt disk data structures, etc.).
Photo of Dan Reynolds

Dan Reynolds

  • 5 Posts
  • 0 Reply Likes
For me , it began with El Capitan.
Photo of pablo antoine

pablo antoine

  • 10 Posts
  • 0 Reply Likes
This is about flexibility of a program to respond to the user needs - and archived folders need a different behavior of Bridge.
I have tens of such folders with hundreds of tif files and it's a pain to go quickly to find a series between hundreds of tif files because Bridge will still stubbornly check for changes and can't be stopped to do it.

I just suggested to have an option in Bridge to not check the files over and over at any opening of a folder - as I said archived folders rarely change and the user can prompt the program to update thumbs if needed.

I have on the same Mac Adobe Bridge, Nikon ViewNX2, IPhoto and My Album - only Bridge and Nikon View exhibit this halting review of the thumbs in folders with large files (4000x2800 pix - there can be hundreds downloaded from a digital camera in one day).

My Album for ex works seamlessly because it doesn't check any updates - it just reads a file it saved when it built the thumbs (and it works from Parallels, mind you). Same about iPhoto - the galleries it made can be browsed without any halting or hanging.

Even an option in Bridge to stop checking files in a reviewed folder when prompted would be enough.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 764 Reply Likes
OK, so your real problem is that Bridge's check for changes to files isn't interruptable (or done in a background thread), so it is unresponsive for a few second when first switching to a new folder?

Disabling the check for changes would be bad.
But the Bridge team can certainly work on making the application more responsive in that particular situation.

iPhoto and most other image browsers also check for changes, but apparently are more responsive when doing so.
Photo of PECourtejoie

PECourtejoie, Champion

  • 781 Posts
  • 280 Reply Likes
Chris, I'm wondering if you should not be attached to the Bridge team, as I am sure that your exceptional code optimization expertise could be useful. I'm sure that there are many routines that could be made faster, multithreaded, etc.
Most of the complaints I hear about Bridge are about its speed.
Photo of pablo antoine

pablo antoine

  • 10 Posts
  • 0 Reply Likes
I checked the folders where this usually happens. There are for ex 1,980 .tif files of sizes around 30 MB each in one - the others similar, all on secondary drives.

The Finder itself has trouble keeping up redrawing thumbnails - it's obvious that Bridge cannot do better without employing a trick like the one I suggested (saving a "last look" only).

Anyway, thank you for looking into this matter. Bridge is already a wonderful tool.
My Best Regards
Adrian
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 765 Reply Likes
Bridge does save the last previews in it's database. EIther the files have changed and it has to recalculate the previews, or just asking the OS for the status of the files to see if they changed is taking a lot of time (and not interruptable). Since the preview/thumbnail update happens a few files at a time and is interruptable, I think we're just looking at a problem gathering information about the files (names, sizes, time stamps -- to compare to the database).

>> While reading the folders in question the drives crackle like crazy and the halting is obviously connected to their noise.

Hmm, that doesn't sound right. That almost sounds like there might be some file system corruption, really bad fragmentation, or bad sectors on the disk. If that's the case, there may not be much Bridge can do to speed it up.

Can you try a similar directory on another physical disk drive?

I just used Bridge CS5 to open a directory on my disk (shared with the OS) with 1400 TIFF, JPEG and RAW images in it that I was browsing last week. It opened in less than half a second and remained responsive. No disk noise, no delay. Opening a directory that Bridge hasn't visited, it takes about 1.5 seconds to show the first thumbnails, then it starts creating previews, and it remains responsive -- and still no disk noise.
Photo of PECourtejoie

PECourtejoie, Champion

  • 781 Posts
  • 280 Reply Likes
Yes, I doubt that Bridge could do better than the finder...
How are those drives connected? USB 2?
Photo of pablo antoine

pablo antoine

  • 10 Posts
  • 0 Reply Likes
No, they are drives in the bays of the Mac. This machine is a workhorse, so the drives are also good quality - and used far under their size (400 GB out of one Terabyte)

While reading the folders in question the drives crackle like crazy and the halting is obviously connected to their noise.

But look, I checked now on my SSD drive, which is connected with eSATA - a similar folder with 997 tif files of same 30 MB size.
Bridge will keep drawing thumbs without halting, even if it's not capable to show yet the contents of wide swaths of thumbs (shows them as empty frames).
Even this last behavior is more acceptable that the halting one on classic drives.
Photo of pablo antoine

pablo antoine

  • 10 Posts
  • 0 Reply Likes
You must have an amazing computer if you don't hear drives reading...
Crackling is nothing amazing for any classic drive - it's the stubbornness of Bridge of trying to read the first thumbs while you want to go down in a folder to -let's say- files with letter S.
It will still want "to do" the top rows - it won't show anything for a while if you drag the cursor to go to the bottom of the folder.

And again, it happens on all drives - including SSD which I described before that also starts to read swaths of thumbs while leaving others showing empty frames for a while.
If it were corruption or fragmentation as you say it will manifest also in other programs - which is not happening. I have wonderful speed in Photoshop, AE etc - loading and unloading files really fast.

Yet another interesting aspect: let's say you leave Bridge to read the whole folder (all one thousand thumbs) and give up on your hurry. Come back to see if it finished 5 minutes later... Surprise!
It shows only the swaths of thumbs adjacent to where you left the window positioned. If you drag the cursor down you'll still discover swaths of empty frames (unread thumbs)...
It looks like it read just a limited cache and stopped bothering about the rest!

Compared to this behavior, Nikon View NX2 for ex at least goes and reads the whole folder if you give it the time - you'll find all thumbs visible without the need to drag the cursor and make it aware that you want to see all contents of the folder.

Anyway, I think I made my point and whatever receptivity I find in your team I can only be grateful that you listen to your users.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 764 Reply Likes
Um, no, I have a pretty normal computer. Only when I get VM thrashing or a bad installer do I hear much from my disks.

Ok, what you are describing is not normal. If you navigate to a new folder, Bridge will create previews for the visible items first, then all the rest. And unless the files are huge and complicated, it should finish after 5 minutes.

I'm not sure if there is something to fix in Bridge, or just some odd case on your system that Bridge should be warning you about.

But we will look into it, and see what can be improved.
Photo of Andres Cathalifaud

Andres Cathalifaud

  • 5 Posts
  • 0 Reply Likes
Hello. I've been reading the messages above, a year old by now. Yet, still speed IS the major problem I and many have with Bridge; a problem that has been with this Adobe product from the beginning (although at first it was a lot worse). The eternal checking of the cache of the files not only makes your application hyper slow but it appears to cause frequent crashes (see below).

I use Bridge in two Macs: a Mac Pro and an iMac. Both Macs have plenty of RAM (over 14GB) and work, otherwise, without problems. Of all of the Adobe Apps I use (I'm on the CC), Bridge is the one that runs the slowest.

As a comparison, a similar program (as far as the user is concerned), Extensis Portfolio (a descendant of the old Aldus, later Adobe, Fetch), displays thousands of thumbnails in "a flash" and it never, ever, has to refresh the cache in the same utterly painful way Bridge does. However slow Portfolio can get at times, it moves at the speed of light when compared to Bridge. This is what I'm looking for as a general improvement on Bridge: Make it work fast, like Portfolio and iPhoto already do.

Thanks.

A.C.

PS: The report on the latest crash of Bridge starts like this (and they all look about the same):

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 000000000000000000 0 + 0
1 com.adobe.dicom 0x000000015fdbf74e 0x15fd64000 + 374606
2 com.apple.CoreFoundation 0x000000010e0908e7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
3 com.apple.CoreFoundation 0x000000010e090846 __CFRunLoopDoObservers + 374
4 com.apple.CoreFoundation 0x000000010e065be6 __CFRunLoopRun + 1062
5 com.apple.CoreFoundation 0x000000010e065486 CFRunLoopRunSpecific + 230
6 com.apple.HIToolbox 0x000000011b7702bf RunCurrentEventLoopInMode + 277
7 com.apple.HIToolbox 0x000000011b77756d ReceiveNextEventCommon + 355
8 com.apple.HIToolbox 0x000000011b7773fa BlockUntilNextEventMatchingListInMode + 62
9 com.apple.AppKit 0x000000010ec97779 _DPSNextEvent + 659
10 com.apple.AppKit 0x000000010ec9707d -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
11 com.apple.AppKit 0x000000010ec939b9 -[NSApplication run] + 470
12 com.adobe.bridge6 0x000000010cc900d7 vsprintf_safe + 33415
13 com.adobe.bridge6 0x000000010cc89139 vsprintf_safe + 4841
14 com.adobe.bridge6 0x000000010cc8920c vsprintf_safe + 5052
15 com.adobe.bridge6 0x000000010cd60037 vsprintf_safe + 885223
16 com.adobe.bridge6 0x000000010cd60664 vsprintf_safe + 886804
17 com.adobe.bridge6 0x000000010c5ffa54 start + 52
Photo of Dan Reynolds

Dan Reynolds

  • 5 Posts
  • 0 Reply Likes
Totally agree. Crashing a lot. I purge the cache and it helps but it really might be time to find new software. This is unacceptable. Started with El Capitan 3 months ago.