Speed drops after extended clip-sequence export

[MilkAndBanana1]

Bug description

Used it auto-editor to a batch file.
Using hevc_nvenc. (ryzen 5 5600H,3060 laptop gpu)
Inputted a 27 minute mkv file.
First 50-70 files are fast, after 100+ it starts to slow down considerably.

What's your platform?

Windows.

What command did you use

set specialparams=--my-ffmpeg --video-codec hevc_nvenc --edit audio:stream=0,mincut=25,minclip=3 --margin 0.05sec,0.2sec --export clip-sequence

rem ##################### SPLITTING THE CLIPS

md edited_clips
set "folder=%~dp0\edited_clips"
set /p inputFile=Enter the name of the file to open: 
auto-editor.exe "%inputFile%" -o "edited_clips/clips.mp4" !specialparams!

What properties does your input video have?

.\podcast23.mkv:

• video:
  • track 0:
    • codec: h264
    • fps: 19001/317
    • resolution: 1920x1080
    • aspect ratio: 16:9
    • pixel aspect ratio: 1:1
    • pix fmt: yuv420p
    • color range: tv
    • color space: bt709
    • color primaries: bt709
    • color transfer: bt709
    • timebase: 1/1000
• audio:
  • track 0:
    • codec: aac
    • samplerate: 48000
    • channels: 2
  • track 1:
    • codec: aac
    • samplerate: 48000
    • channels: 2
• container:
  • duration: 1629.044
  • bitrate: 102590866

Metadata:
ENCODER : Lavf60.3.100
Duration: 00:27:09.04, start: 0.000000, bitrate: 102590 kb/s
Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 1k tbn
Metadata:
DURATION : 00:27:09.044000000
Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp
Metadata:
title : Track2
DURATION : 00:27:08.992000000
Stream #0:2: Audio: aac (LC), 48000 Hz, stereo, fltp
Metadata:
title : Track3
DURATION : 00:27:08.992000000

Comments

Have a feeling this is just CPU getting fried after multiple encodes but issuing this in case there's a potential optimization.

[MilkAndBanana1]

Update: Merged the audio tracks and ran it through ffmpeg before doing so and it seems to be faster.

[WyattBlue]

I already know auto-editor can be slow when exporting as a clip-sequence when there are hundreds of clips. it's an O(n^2) operation due to file seeking being linear. I don't consider this a valid bug because I only have so much time on this earth to be spending time optimizing every last use case.