Is there a way to TURBO speed up premiere pro even more by making it use more GPU?

[Bed30321077z973]

So I am performing lot of tasks right now, inserting numerous items to the tracks,

But I don't find it fast enough for me.

I want it to become REALLY REALLY insanely fast, be it if that meant HUGE use of GPU.

In the following screenshot I am showing what a machine is diplaying in term of GPU, CPU and RAM usage when running extendscript, I have another machine with more gpu than this one but in both cases the usage of GPU is not thaat important:

Something like pytorch (used in machine learning) something similar that would boost Premiere pro by using more GPU?

Maybe the slowness comes from javascript itself? Or both Premiere pro not being optimized for heavy use + javascript slowness?

[Bruce Bullis · Accepted solution]

Without seeing your ExtendScript code, there's no way to provide any meaningful feedback on what might speed up its execution. Currently, there is no reason to think that moving to GPU processing, or machine learning(?!), would help anything.

[Bed30321077z973]

Importing the same item from media library to tracks multiple times. I want it to be WAY way faster.

That's the code essentially.

[Bruce Bullis]

By 'media library', do you mean 'project panel'? 

[Bed30321077z973]

Yess! (A project item from the list of items I have in the project)

[Bruce Bullis]

Please send me your ExtendScript, and the project & media that are acting slow for you.

[Bed30321077z973]

Yes, thank you for the offer. I will try to remove the logs first and experiment with it, maybe that can help somehow. And try to tweak it more, but as soon as I am giving up I will send you the example so you can see. Thanks again!

Probably tomorrow

[Bed30321077z973]

Hello again,

I would need to make a new  project that does the same thing as mine, but with random files, so you can reproduce it, that's why I wasnt able to send you the project to reproduce it.

It's simple to reproduce, take on project item, and insert it to the timeline with different in and outs and different insert time (makign sure they dont supperpose, (although overwrite could be used for the experiment?, I havnt tried it yet because I dont want it to overwrite))

In the meantime I have more info, I have done more experiments:

What I have noticed is that the more items ther is "OVER TIME" the slower the "api response, or PPRO reponse?" to the commmnds get.

For just 100 hunder insert command: 36.9 secs => 0.367 per insert()

if you add 4 more items while adding those 100 firts items (kind of in parallel, i mean its 5 items by 5, 100 times, but that does mean anything because ites probably sequential anyway, anyway the total of inserts would be..see text after parentheses), for a total of 500 insert() within a short time, you can do it in 62 secs => 0.12 an insert()

So we are getting FASTER with more item, but this is only because its the beginning!

Now the problem comes when continue to add stuff LATER ON,

From the experiments I have done, Here is what I can report:

After severals tens of hunderds of "inserts" I noticed that inserting 5 items, would take 9 to 10 seconds.

We are down to One insert() per 2~ seconds?

Which is actually ULTRA slow.

Whereas in the first hunderds of inserts, the process was quick and fast, 62 seconds for 500 items or so. That's like: 0.12 seconds an insert!

But later on, My timing was: I can add 500 if I wait (500x2seconds.. ), so that's 1000 seconds, = 16.67 minutes . :(, that's really a lot! Especially if you have another 500 items  (we are up to 30 minutes, then 45min.. then 1H process, yes yes 1h process)

I will have to try to make a ready to use extendscript for you, but I will need time for it, but if you are curious and can make it faster than me, then as I said, simply make a process that use one project item and insert it in the track in different times about severals tens of hunderds of time and YOU WILL OBSERVE how insert()s will get very slow (I went from 0.12s per insert to 2 seconds per insert which is very significant)

If any idea comes to mind, please do share. I will continue experimenting to see.

[Bed30321077z973]

I have even MORE info:

Actually it was 600 items not 500,

The most disturbing here is that, I think this WILL SUPRISE you:

If you have a duration in the time line called "duration", and you:

Situation A): add one projectitem to the same track, about 300 times, all over 3x the duration.

Situation B): add addi 600 items withing 1X duration (so within 3 times less portion of the time line)

Situation B would be much faster: 0.12s/insert, situation A would be 0.43s/insert.

Extra situation:

- Situation C: if you just insert 100 items within 1X duration. You would not get faster than inserting 600 items within the same duration. (0.367 per insert() as previously stated)

here is an illustration :

[Bed30321077z973]

I might have discovered the source of the problem:

I tried to run the program in a way it treats different portion sof the timeline every run, so I would run it, it ends, then re run it (no breakpoint here just running the program multiple times)

and each time I would treat different portions of the timeline,

First obsevration:

The later the timeline is, the SLOWER the inserts were, for instant:

- Inserting 200 items in the first part of the timeline: 0.36second per insert

- Inserting 200 items in the part prior to the last part would have a rate of: 1.03s/insert

- Inserting only 100~is items in the LAST part of the timeline: 1.26s/insert (even slower than inserting 200 items in few moments back in the timeline)

Theory: Could it be somehow just the target area of the timeline affecting the inserts? If yes, why?

Another theory: could it be because my in's and out' are bigger the more I advance in the timeline, and that causing extra computation time? I think so.

In that case, creating subclips could be better choice after all! I will to explore that now ... I suppose.

[Bed30321077z973]

ANOTHER theory (confirmed) is:

The more there are items on the tracks, the slower inserting new tracks get!

I know it because I did the experiment:

Added 100 items to a project had numerour other items before, is slower than adding 600 items to a project that has no items, even if its has bigger in and outs (they have no effect on performance), and even if we are at advanced times of the timeline (as long as there is no item BEFORE). (I did not experiment for items present AFTER, i mean, lets say we have numerous items at the end of the timeline and we want to add 100 items BEFORE them, I wonder if it will still get slower or not).

One solution would be to open multiple projects at once, and having items added to multiple timelines, so reduce number of items within one timeline,

But I have no idea if we can run the code on multiple projects at once or not, and if the performance will split or not.

[Bruce Bullis · Accepted solution]

Interesting speculation.

As before: If you can provide the actual ExtendScript you're using, a project w/media, and (IMPORTANT!) step-by-step instructions that reliably reproduce the behavior, we'd be glad to pursue it further.

[Bed30321077z973]

Understood.

Final observartion (probably), and suggestion:

I noticed that time was also heavily increased by other functions other that "insert", for instance performing setInPoint and Out, or getInPoint or Out. etc. had a huge impact, regardless of inserts and quantity of items in the tracks.

For instance:

Having an empty track (so we don't have the problem I noticed earlier), and :

- 1) adding to it 500+ items (inserts) with 500+ in and out setters and getters + prints = 88 seconds.

- 2) the same as 1), + performing 500+ extra in an out set and getters without ANY extra inserts added = 157 seconds.

- 3) the same as 1), + only adding 500 "inserts" (on another empty track), no extra prints, no extra setters no extra getters = 115 seconds (as previousely stated in another experiment related to using multiple projects).

What I wish for we had:

Is having a ProjectItem constructor, the same way wa have with Time (var timeA = new Time();), trying (var ProjectItem A= new ProjectItem()) gave: "ProjectItem does not have a constructor".

Although that's a maybe a problem with privacy or whatever.

Why this wish? to be able to "store" the Project Items inside text files, and be able to SEPARATE the process of creating them (with ins and outs etc) from the process of "inserting them".

Indeeed INSERTING seems to take no time if the track is empty, I would like to do all the pre processing (setting ins and outs and store that) THEN only then start inserting.

Just ideas out there lol.

[Bruce Bullis]

>Final observartion (probably), and suggestion:

As stated above, and previously... If you can provide the actual ExtendScript you're using, a project w/media, and (IMPORTANT!) step-by-step instructions that reliably reproduce the behavior, we'd be glad to pursue it further

>What I wish for we had:

>Is having a ProjectItem constructor,

There is no API around a projectItem constructor, because only PPro can create valid projectItems (usually, via importFiles()).