Br 12 vs Br Beta -- performance results

[BruceVI]

Before beginning, I should probably post up my pedigree.  I was invited into the Bridge prerelease program ca. 2005-06 by Chris Cox.  I have tested every prerelease, release, and beta version of Bridge since then.  That’s likely in the vicinity of 100+ versions and many thousands of volunteer hours invested in assisting Adobe in the development of Bridge. 

I have used Br as the primary asset management tool in our studio’s production environment for all that time.  It is unlikely that anyone in this conversation has significantly more experience in testing and using Bridge in a high-volume production studio than I do.  My testing parameters have been refined over the years to provide the most accurate, predictable, and repeatable results. It works well in all our studio folder hierarchies. Your conditions are not ours, so your milage may vary.

Here are the parameters of my most recent performance comparison.  The test bed is a brand-new Windows 11 laptop with an AMD processer comparable to a higher end i7 laptop. 

The attached videos will demonstrate the relative efficiency of Br 12 vs the latest beta build of Br 14 when browsing a hierarchy of folders that contains the following:

• Total file size of the folder hierarchy 14,659 MB
• Number of folders: 25
• Number of files: 4076
• Roughly half of the files are a mix of Psd, Png, and Tif files.  The vast majority of those are less than 4 megabytes each.  The other half are proprietary txt files (.flame / .chaos) that serve the same purpose to their parent software as .Xmp files serve to their companion RAW files.  Those are only a few kilobytes each.

I have given both Br 12 and Br beta their own independent cache location on the primary drive. All of the files have been cached in advance by both builds to eliminate caching behavior as a performance variable.

The process of the test should be obvious from the linked videos below, but in short, Bridge is launched and a folder hierarchy is collapsed to reveal all the assets in that hierarchy. Immediately an attempt is made to operate on those assets, in this case using various filters to narrow the selection down.  This is a common daily activity in our studio.

It has been well known for many years that there is typically a slight delay when accessing the subfolders of a hierarchy while Br accesses the cache and generates thumbs. Accessing thumbs from the cache takes some time. The performance in the filter panel in Br 12 and earlier is not affected by this.  Br 13 trashed that performance, and the results still remain in Br 14 as you will see in the following videos.

Also notice the fact that the valuable arrow keys on the panel scroll bars were eliminated with the first Br 13 release and never returned to the interface, while giving no equally valuable alternative in return. The feature was simply removed, or perhaps more accurately never incorporated into the new architecture. Why?

As far as the conversation about scrolling speed of thumbnails is concerned, I would submit that hobbyists and other casual users may not notice the inconvenience.  On the other hand there are many, many highly skilled artisans who have had their studio’s productivity severely compromised by this defect.  It took years of effort, testing and feedback from prerelease testers to help Adobe establish the performance level of Br 12.  A great deal of that progress has been severely damaged or destroyed by the new architecture.  Of that much I am certain.

I’ve seen a number of inconsequential features added to Br over the years, but at least those changes have always been easy to simply ignore. The destruction of years old professional workflows that has been wrought by the subjugation of Br 12 by Br 13-14 is impossible to ignore. The pity is that Adobe was repeatedly warned about this eventuality beginning almost 20 months ago, before Br 13 ever became a public release.

Here are links to the head-to-head testing results of Br 12 vs the latest Br 14 beta. I’ll leave them on Dropbox for a bit, but I’d recommend downloading the two files to your local drive for the most accurate results.

[Lumigraphics]

I'm currently working my way through a set of about 90,000 files, local SSD on a 2019 MacBook Pro, about 90% JPEG with a few PNG and the rest PSD files, dual displays, mostly with two Bridge windows open and a number of my custom scripts running. Bridge 12 is somewhat ok for performance until it (repeatedly) crashes. Bridge 13 and 14 are pretty much unusable in this scenario. I have to use Spotlight for Quick Search (upper right corner) because Bridge search regularly misses files. User apps running are VSCode, Photoshop, and Bridge 12.

I wouldn't drive Bridge this hard if I didn't need to but doing product photography professionally, this is how it goes.

[MazStudios]

Thank you for making such a good comparison. The 13-14 is a clear sign that something is very broken at adobe. Or at least, the adobe team.

I have made several posts about this being very blunt about the fact that Bridge 13-14 IS broken. i have never gotten any feedback what so ever. One time they actually connected to my computer to see how slow Bridge was. They said they could replicate the problem. but when the final version came out, it was barely noticeable. Maybe a few %.

I for one really like the idea behind the tabs. It's really usefull. But if THATS the reason everything is broken, then it really has to go. I, as many other, cant upgrade from 12 yet. Its like 13-14 is a highly experimental Alpha not intended for relase.

WHAT happened to the team? Have they been replaced by a new without the knowledge. WTF is going on? This is truly beginning to look like Bridge is going away or replaced by some simplyfied mobile app not directed to the pro-market. With lots and lots of AI GUESSING what images you want to cull for the day. I dont know 🙂

So, thanks again for this post.

Moving on. Since we dont get any answers from the team, does anyone have any contact info to people higher up the chain? Maybe go straight to the CEO and let them know whats going on?

Since it's the company is based in the US the hierarchy is probably very compartmentalized and people higher up doesnt have a clue about whats going on. otherwise there would probably be layoffs.

So, any mails we can start to spam to get the wheels going?? 🙂

[BruceVI]

Maz.  You said: "I for one really like the idea behind the tabs"

You said "tabs" which have been around as long as Br has.  Were you intending to refer to the new tear-off panel feature  instead? 

[MazStudios]

Yes

[BruceVI]

Thanks for the clarification.  I’ve long suspected that a significant factor contributing to the massive performance hit across several areas of 13/14, might be a result of the dock/undock panel feature.  The feature is useless to people who long ago learned to understand the value of properly customized, windowed workspaces. Alas, without an understanding of the code underlying the new architecture it remains speculation.  I suspect that the feature was repeatedly requested by people who have never understood or significantly employed windowed workspaces in their workflows adjacent to the other primary application(s) when sorting and serving up assets to them.

Of course, I can choose to ignore docking/undocking right up to the point that something that caters to less experienced casual users, wrecks the productivity of  widely experienced, professional users of Bridge.

The backlash against the removal of the multi-instance feature back in 13, (and its subsequent return a year later), may have caught Adobe flat on their feet and entrenched in a bad idea as witnessed by the fact that launching additional Br windows have their undocking disabled upon creation.

One could make a very strong argument that it should be a design choice between one or the other, but not both.  If the current horrific performance is a function of the code necessary to sustain the undocking feature, then it’s hardly a choice at all.

[gary_sc]

Hey Bruce (THE SIXTH), for a guy who claims he knows Bridge better than anyone else on earth, maybe you need to define what YOU mean by tabs. The tabs that I and many, many others have been asking for since Bridge v.1, didn't show up until Bridge 13.

And yes, the tear-off panels are also something that many folks have been asking for, but a tear-off panel is not, in and of itself, a tab.

[BruceVI]

Tabs are the same tool they have been ever since the days of manila paper folders stored in metal filing cabinets.  They are a functional way of quickly locating and bringing one set of information to the center of a user’s attention.  In Bridge, every panel has a tab that allows that group of information to be brought front and center or moved somewhere else within the UI. 

Obviously, that has become not so obvious. Sadly, the design team has chosen, (for no clear reason), to change the UI color/contrast to the point that a user can no longer see where one tab stops and another one begins. This unfortunate choice diminishes the tool’s usefulness by introducing ambiguity and eye fatigue that many times leads to mistaken clicks and drags.

[gary_sc]

Oh, you mean the different Panels. There has been so much angst with the Tabs in the Content Panel that that's what I thought you were referring to.

No argument on the visual changes. When I first saw it, I thought that this was the skeleton view before they filled it in in later builds. Unfortunately not.

[BruceVI]

Not precisely, no.  I was referring to the tab extensions at the top of every panel including the content panel(s).  Your comment seems to imply that you believe that there is a single content panel with multiple tabs when in fact the + sign on the tab of any content panel produces an additional content panel that can be independently docked/undocked/moved anywhere in the Br UI.

I’m not certain what angst you’re referring to. The feature allowing multiple content panels is a welcome addition.  Unfortunately, that and the keyboard shortcuts feature don’t come anywhere close to offsetting the significant performance issues and bone-headed design changes that continue to plague the 13/14 era and dissuade power users of Br from migrating away from Br 12

[Lumigraphics]

I think multiple content panels is a huge step backwards. Multiple windows were a much, much better solution.

[Phoo34734747txhb]

Thanks for the demo.  I’m seeing some of the same type of lag in the folder panel when moving up and down through subfolders.  Sometimes it takes several clicks on the carrot next to the folder name to get the subfolders to show and hide.  It isn’t a constant.  It’s more random and not really reproduceable in a bug report.  Is anyone else seeing this annoying random behavior?

[Erik Bloodaxe]

Yes, I observe similar lags. In particular when I click on a folder to access its subfolders, sometimes two or three attempts is necessary to accomplish this opening. The delay is frustrating at times.

[Lumigraphics]

I've seen mysterious stalls and lags from every version since I started using Bridge.

[BruceVI]

Yup Phoo,

I too suffer the same transient performance issue when navigating the folder panel. It has appeared in every test and release build I’ve tried for way over a year. Furling and unfurling are not consistently instantaneous on every attempt as they are in Br 12. Sometimes only a single click is missed.  Other times several clicks are missed when attempting to reveal/hide a subfolder. Many times it works as designed. This sort of unpredictable transient behavior shouldn’t still be affecting the application after almost two years of less than professional 13/14 performance.

I demonstrated this to Swati Agarwal and three other members of  the Br design team, (whose names I forgot to record), early last November when they visited my production environment. I pointed out these transient missed clicks as well as a several other long-standing performance/design issues that have been persistent and repeatedly reported ever since…forever?!?

They all agreed it should not be happening. Two months and two test builds later the defect still exists. 

Similarly, there is the long-requested addition of a zip/unzip feature that still doesn’t allow an option to unzip files to the same location as the compressed file. It took less than five minutes to discover this flaw the first time I tested the feature. The incomplete feature forces a manual solution in Br to an automatic unzip behavior that has been available in Windows Explorer for as long as memory serves.

I pointed this out in the very first prerelease appearance of the  Zip/Unzip feature back in July.  Adobe’s Tanu Goel announced at that time:  “We’ve added this to our engineering issue pipeline”. 

 Exactly where is it being piped in from? Neptune? 

• Do things once, efficiently.
• Do things automatically whenever possible.

Some folks should have that tattooed on their foreheads.

[Swati Agarwal]

Hi @BruceVI ,

Thank you for your patience, performance issues for Filter and Folders panels are under investigation. 

Regarding the behavior of zip/unzip feature, to incorporate user's feedback, the following configurations had been added in Preferences -> General for user to choose the location of extracted files.

Regards,

Bridge Team

[BruceVI]

Sadly, your team never fully understood the unzip problem.  I’m aware of the option(s) you pointed out.  I've been aware of them ever since they were introduced.  None of the available options solve the problem I pointed out back in July during prerelease. Regardless of which option one uses, one still has to navigate to the archive folder, manually drag the unzipped file(s) back to the folder which contains the zipped archive and then manually delete the empty Archive folder. There is far too much opportunity for error in this scenario as well as needless wasted time. Here is a visual showing the results of the two different methods with just a handful of files.  Imagine a scenario with several hundred zipped files.

If you are going to emulate a process that has served customers for decades in Explorer, your team should have taken a closer look at how it traditionally works and designed the implementation accordingly instead of handing out half a loaf and expecting customers to swallow it without question.

That same lack of attention to detail has been evident throughout the Br 13/14 era, both in the code optimization as well as the design concepts that the code tries, but largely fails to support.

• Do things once, efficiently.
• Do things automatically whenever possible.

Since I’ve clearly demonstrated at the top of this thread that the existing filter lag is unacceptably bad, why would the release announcement for the latest beta drop state that the problem has been fixed? Moreover, how did this faulty optimization ever make it out of testing and into a released version of the application in the first place? Ditto the folder panel clumsiness, though I suspect that these are two sides of the same coin.

Br 14 remains a broken and unreliable option compared to Br 12.  Unfortunately, it has always been that way. The architecture has been broken for almost two years.  Someone repair or replace it, would you please?

At the very least, the last release version of Ps 2022 should be returned to the CC application for those who are transitioning to new hardware and require a Ps version that fully interfaces with Br 12. Currently that option remains unavailable.

Many Adobe customers have  been patient enduring this debacle for way, way too long!

[Navkamal Rakra]

Hi Bruce,

Thank you for your support and patience. We are consistently working on improving the quality of Bridge and resolving the issues faced by users.
Regarding the "Extract here" functionality for zip/unzip feature, this functionality is not available in the Windows native version either. You may have another application like WinRAR or WinZip installed, which is why you're getting that behaviour in Windows Explorer. Could you please check and confirm the same, also share the screenshot for the option.
The behaviour of the extract functionality provided by Windows and MacOS differs. In Windows, it prompts the user to choose the folder where the files need to be extracted, while in MacOS, files are extracted into a folder with the same name as the zip file.
To support both MacOS and Windows, we took the decision to have a uniform behaviour for both OS platforms.

Regards,

Bridge Team

[Lumigraphics]

If you use ditto on Mac like you should, unzip puts files in a hierarchical folder structure.

[juno28415894wgs8]

Hi, what is the best version number for Bridge right now?
Be more specific, is it 12.0.3.270?
The new version 2024 is slow and too memory intensive 。。。。。

[BruceVI]

The only version available to me in the CC app is 12.0.4.286.  I believe it to be the last release version of 2022 (Br 12).

[juno28415894wgs8]

thank you!

[BruceVI]

YVW!  Let me know if you can access a 2022 version of Ps so that Br can connect with a compatible version.  I don't see Ps 2022 on my list.  The one before is there, as well as all the subsequent versions, But not the one that works with Br 12.

[juno28415894wgs8]

I'm using br 12.0.3 and PS is 21.0.3, and this version is the one I find the smoothest.
But I have too many versions of br and PS installed, and it's not easy to uninstall them, and the current BR and PS are not transferable.
I have a program that says it will work with either version of ps and br, would you like to try it.
Please leave your e-mail.