Why does Pr get slower and slower, this is getting ridiculous?

[Rob Ainscough]

Any moderate to large scale project is painful to work with ... even with proxies, which one CAN NOT do when color grading, performance is horrible regardless of how much hardware I toss at Pr?  I'm working with a simple conversion of 5030 .jpg images (one per frame) into a video and I can't even edit the sequence nor change the duration.  Heck sometimes it will not even show me a program image from the timeline.

To put this into perspective, I can use "HitFilm" express (which is free) and load my 5030 .jpg files and generate a video sequence without any issues.

I'm a software engineer and I'm aware of performance pitfalls, but I hate to say this, but your development team need to revisit the basics.

Come on Adobe, what the heck is going on with the your development team?  I've thousands of $$$ with subscriptions to Adobe and I'm simply NOT getting my moneys worth ... it's shameful.  The number of threads I've seen in regards to performance problems is staggering, as an engineer I would be embarassed to be associated with Adobe's software development efforts ... certainly wouldn't add Adobe to my resume.

I wish I didn't have to be this harsh, but I've just had enough of subpar performance from Pr and Ps and Ae.  This really is not good enough, not even close.

Rob

[Warren Heaton]

Hi Rob:

Sorry to hear you're experiencing poor performance.

I've found Premiere Pro to be running extremely well with ProRes under macOS and Windows.

To convert a JPEG image sequence to video, I'd use After Effects instead of Premiere Pro.

-Warren

[Rob Ainscough]

Every performance solution for Adobe seems to be "convert to ProRes" which I already know about ... the issue there is time and space ... time to convert and the increase (considerable) in storage space used.  Other editing platforms don't seem to have any such requirement and work extremely well all native formats/codecs ... no one at Adobe seems competent enough to explain why they can't?

[Warren Heaton]

@Rob Ainscough 

Hi Rob:

Other editing platforms do have such a requirement.  In Avid Media Composer, the default editng CODEC is DNx; however, via Avid Media Access (AMA) ProRes can be used instead.  In Final Cut Pro, the only Proxy CODEC and Optimized CODEC is  ProRes.  In Blackmagic Davinci Resolve, Optmized Media and Render Cache project settings allow the user to choose betweeen ProRes and DNx for Proxy media format and Optmized media format.

In Premiere Pro, users can choose from any of the Smart Rendering CODECs.

-Warren

[Rob Ainscough]

We'll just have to disagree on this one ... upto about 2017 Pr had no problems working with some of the CODEC commonly used ... the conversion to x64 seems to be the root cause.  Anyway, I've circled this wagon long enough and it's painfully obvious nothing is going to change on the Adobe side.

[R Neil Haugen]

I have no clue about expecting everything to be done without proxies or t-codes. Seriously.

I am around a lot of colorists, with MASSIVE machines blowing my 24-core 128GB/RAM 2080Ti with a pair on Nvme drives for OS/cache and six other internal SSDs into dust bunnies. On a daily basis.

These folks are based mostly in Resolve, though some are in Baselight.

A continual discussion amongst them is using proxies v optimized media v render cache. And at the moment, it's split between more using proxies and at need t-codes vs those still using "optimized" media. With comments about why anyone would still use that old thing.

So these heavily experienced Resolve and Baselight users, on massive heavy iron, use proxies & t-codes every day. For anything that's hammering their machine.

Like DPX ... which quite often gets at least a proxy, if not a full t-code then offline/replace to original prior to export.

On machines that play 8k RED without issue.

But DPX sequences, anything long-GOP, and some other messy formats get proxies or t-codes.

What works ...  works. I'm very practical that way. I'm not into affection with software. Especially since they "killed" SpeedGrade ... these are all just tools. All work a bit differently to do essentially the same thing, and some work better for certain hardware/OS/media/effects needs than others. They can all pretty much do "the job".

You learn to use the tool the way the tool works. I was taught that as a kid on the farm. If you're working in Premiere, you do what works in Premiere. If Resolve, what works in Resolve. It won't be the same process, but there is one to at least eventually get the stuff done in each.

These apps are all fancy hammers, that's all.

Neil

[Rob Ainscough]

I guess we disagree Neil ... with current hardware 32c/64t CPUs, DDR5, M.2's, GPUs with 82 TFLOPS at FP16/FP32 is some serious computing performance ... where working with 5030 4000 x 3000 res files would barely register as "activity".  My PCs can process 75GB/sec thruput (not theoretical) data no problem.

When I'm editing there is hardly any CPU or GPU activity.  I would expect Pr to have all my cores working to prerender whatever format it needs to display an image correctly in a sequence, but I get nothing until I move my playhead to a location then I get ONE CPU pegged at 100%.

CUDA seems to be only used on exports or render outs not during editing nor proxy generation ... makes no sense to me?  Editing is the #1 operation for me ... I assume most either send out final to a render farm or their own render servers (I use my own in house) so it's really not that big a deal ... it's the editing that's the problem.

Even with photoshop, exporting a simple 4K image to PNG for some bizarre reason takes 10-20 seconds?  Something that takes <1 second in Windows Paint/Photo app?  

Sorry, but Adobe have some serious performance issues that they can't seem to or don't think are important to solve?

Software is not physical, tools are locked into the physical realm, can't really compare.

Like I mentioned to Warren below, I think the issue is the use of abstraction layers in coding trying to maintain a single code path for both iOS and Windows.  This is the LCD approach to software engineering across platforms, cheaper development costs at the cost of less utilized and highly specific accelerated hardware instructions.

But again, if editing in Pr is going to be such a horrible performance issue, then the golden rule for software development is to provide the user with a "progress indicator" to shows users that it is working on something even if very slowly.  Right now, there is NO visual queue (unless you're like me and monitor activity via task manager or some other tools) in Pr to indicate it's "thinking".  That's just a bad UI.

I honestly don't understand why some of you defined the poor performance of Pr?  You know it's poor because you and I have work around after work around to try to improve it. 

I was taught to use the right tool for the job also, Pr isn't that tool.

[R Neil Haugen]

You're essentially running a 5,300 pixel width ... about a 5k ... DPX sequence there. Right?

I can run 4k BRAW, RED, Arri, and even H.264 on my 24 core Ryzen without troubles. Both Premiere and Resolve.

But if I was trying to run a 5k DPX in Resolve, I know good & well it would hammer my machine. I know & work with a lot of colorists, and they typically proxy or t-code large DXP sequences to do color. And that's on hardware A LOT beefier than mine.

I don't know why you couldn't do playback with proxies while doing color work.

But we all do have our preferences.

Neil

[Rob Ainscough]

Again, I'll disagree.  I've got legacy Pr 2017 version running and these image files (5030 image file count not pixels, jpg at resolution 4000 x 3000 at 2382KB per file) ... in fact, that's what I do, load Pr 2017 if there is nothing in Pr 2022 I need for the project.  Pr 2017 has no performance issues with processing these files.

If Adobe continue with their performance problems and/or just ignore users, I don't see much of a future here?  I know I'm not alone based in the feedback I've received from many many users.  

One major software engineering "best practices" is to provide a user with long running process feedback ... what I mean by that, is if a process is going to take more than 2-8 secs it needs to have a "progress" UI indicator ... no such indicator exists in Pr when working a sequence.  Pr leaves the user guessing on what's going on, this is NOT GOOD and every software engineer I've worked with over the past 35 years knows that's a bad interface.

Here is an old article going back to 1990's discussing UI response time, it's actually gone down to 2-8 seconds max before a progress feedback is required.

If Adobe can't figure out their performance problems, then they should at a bare minimum provide UI feedback.

[Warren Heaton]

In the 1990s we used high-end digital disc recorders to lay 900 frame 720-by-468 Targa image sequences to tape (D1, DigiBera, or Beta) in real-time at post production facilities at a heafty hourly rate.

Longer animations could be laid off to tape very,very slowly one frame at a time with a dedicated system (I forget the name of the hardware that we used at CalArts for tape layout from an SGI workstation, but it took forever).

If you're able to get real-time image sequence playback without any rendering from Premiere Pro 2017,  don't change anything about that system.

[Rob Ainscough]

That's interesting, but not sure what it has to do with Adobe's performance issues post 2017?  Having to keep a 2017 version operational on one of my PC's shouldn't be a "solution" to problem.  Adobe still can't get the basic Meta data information correct for many sources ... that's really basic programming.  Again, it's as if they're all Mac/iOS developers using XCode and no one is proficient with Windows OS programming using Visual Studio.  The performance problems with Pr 2022 feels like an abstraction layer rather than fully utilized hardware level accelerated operations which I know C++ is more than capable of working with.

Adobe have the financial resources for two development paths (Windows/iOS), but given their current announcement regarding running on iPad it sounds more and more like abstraction layers where the code has no direct path to low level hardware to utilize it's potential.  The advantage to code abstraction is having a single code path, the disadvantage is performance as the abstraction layer has to operate at LCD (lowest common denominator) in order to maintain cross platform compatibility ... in other words don't utilize very specialized instruction sets/drivers/hardware.

[Warren Heaton]

You linked to an aritcle from the 1990s, so that's what it has to do with "anything".

I don't agree with you about diminished performance.  I'm seeing full frame, full motion playback of 8,192-by-4,320 Apple ProRes 422 HQ footage from M2 storage on my 2019 HP Omen 15-inch laptop and Flash storage on my 2021 Apple M1 Max laptop.  If I was looking to load and play an image sequence at that frame size, I'd use After Effects or Chaos Player.

If there's something that the Premiere Pro team can do to improve working with 12MP or 48MP images in Premiere Pro without having to down-covert them in Photoshop first, that would be welcome - but that's as true of Premiere Pro 2017 as it is 2022.

[Rob Ainscough]

Because the UI best practices hasn't changed much since the 1990's ... if a task is going to take more than 2 seconds you provide the user with visual feedback (otherwise they think the PC is locked up that triggers a reboot or end task, not good).  So if an edit session on sequences is chugging along, show the user something to indicate it's chugging along.

Like I said, I understand converting to ProRes seems to help in most cases, but it's a step that should NOT be required.  All that tells me is that Adobe don't have a handle on how to decode compression scheme's other than ProRes (or the small fraction they seem to support).  They have the money and development resources soooooo...

[Warren Heaton]

If you follow the Smart Rendering link, you'll see the full list of supported CODECs for editing.  Arguably, it's longer than any NLE currently available.

[Rob Ainscough]

Oh you mean the "Restricted" Rendering link 😉 

Honestly, don't care to compare externally, that doesn't solve problems specific to Adobe.  I'm really not sure why some of you are defending Adobe's performance problems as "expected" or "acceptable" ... I'm not alone in reporting performance problems with Adobe Pr ... threads and long and wide on these forums with many users have the same performance issues.

If Adobe are unable or unwilling to address their performance problems, then provide user with a simple visual queue that it's working via a progress bar or something else ... Pr breaks all the software engineering "best practice" rules I know for working a UI that is supposed to be "responsive" (no thread blocking).  Much of the progression of software engineer over the decades has been focused on prevention of UI thread blocking.

[Warren Heaton]

https://helpx.adobe.com/premiere-pro/using/smart-rendering.html

[R Neil Haugen]

We're users like you, and that's who you're communicating with here. As this forum is primarily user-to-user 'help'. And I'm not defending their setup or Adobe in any way. I don't have a clue why so many people these days think being able to explain something means you're defending it.

The two things ... explaining and defending ... are not at all related as far as I can see. I can explain a ton of things I personally find disgusting, without feeling any ned in using any pejorative reference or comment at all. My opinions aren't part of the explanation. They're separate from understanding how something works ... or doesn't.

Ya wanna talk to the Devs, you post on their Uservoice system ... that's the input portal to the engineer's system. Every post there is manually logged into the system and tagged for attention to the appropriate section of the staff.

And yes, I've talked with the engineers doing that work, and they told me that they like my posts because I gave them a ton of information on the problem and my setup & such. Enough they could get a good handle on trying to replicate.

Most posts are of the nature of "X is broken. Fix it."

Well, if it ain't 'broken' on any machine they have access to, and that's the only "information" ... they are probably going to note the post exists but it's of no use past putting a number on a board of people having trouble with some part of Premiere.

And of course remember that the userbase is several million daily users. Each one of us is a very, very small fish in the ocean. I would it were otherwise, naturally.

I find the performance thing a massive puzzle. It used to be much simpler to sort out general performance issues. Tell me your media, hardware, and effects, I could pretty much clue in on very specific steps to solve the problem.

Now ... both in Pr and in Resolve, which I also use ... performance across the user base is all over the freaking place. There are people posting here with new M1 setups that are not hardly able to work, yet ... many thousands of other new M1s are screaming along.

Apparently running similar media & effects ... what the ... ?

And it's the same on PCs too. And as someone who likes troubleshooting, this is very, very frustrating.

The devs tend to be more Mac folk than PCs, but they run a near equal number of machines "in the shop", and work to keep quite a variance of hardware. "The shop" is of course the many offices the various team members work in all around the world. Pr's "mothership" is the Adobe home of San Jose, but they've teams of people in many other places.

Neil

[Rob Ainscough]

I'm not disagreeing with users being all over the place.  But, the way I've dealt with my users is I provide them the ability to log sessions and either log direct to a web service that puts the data in a SQL server or to local file when is sent to a special email acocunt ... then I can analyze the data to see what's happening.  The apps I've created, I provide users the opportunity to enable a debug mode via the UI ... this adds a little overhead but not much.

If that doesn't help, I can enable remote debugging (this takes some additional installs and firewall settings on the client side) and I can use VS to Attach to process on a remote PC and debug their executing code on their PC as if it where on my local development PC.  Microsoft Visual Studio 2022 Pro/Enterprise is a very powerful tool.  Has anyone at Adobe actually performed a remote debug session on an end users's PC?  Software Engineering has come a long way ... I'm happy to offer up one of my PCs for remote debugging as I know what I need to install to make that work ... of course it does mean the Adobe developers need to be using MS Visual Studio and the exact deployed code set for the specific version of Pr and it's components.

I've gone thru Adobe's other "voice" and "feedback" channels and they are frankly a waste of time, I've had more direct engineer feedback from this forum over the years.

Cheers, Rob.

[Warren Heaton]

https://community.adobe.com/t5/premiere-pro-discussions/faq-where-do-i-find-premiere-pro-crash-logs-...