wrap stabilizer -project file size

Doing render & replace to say ProRes 422 will increase the media space as opposed to the original clip, as that format is larger on disc than long-GOP media. ProRes is an "all intraframe" or all-I format. it doesn't overwrite, it creates a new clip.

You can select that in the sequence and choose "restore unrendered" and it goes back to the original clip ... useful if you need to change say the Warp.

Although the clip of rendered ProRes takes more space than the original does, as you are eliminating a truly massive amount of project data, your project file will drop in size and be a far simpler set of data for Premiere to work with.

Some general information ...

H.264 is a "long-GOP" codec, meaning there are only a very few actually complete frames, called "i-frames". Between 1 every 9 (old school long-GOP) or now, especially with DJI drones, 60 or more partial b and p frames in-between iframes.

The p an b frames are simply data sets of a) pixels that will change before the next iframe or b) pixels that have changes since the last iframe or c) both.

With the specialized additional chips to do the encoding in capture devices, this can drastically cut down the data space needed to write the video to file. It's really handy for that.

BUT ... in playback, it's a problem, isn't it? Because the computer has to figure out what to do simply to display the next frame ... and must decode/store both the previous and next i-frame, sort what pixels to create for 'this' frame, and what to grab from either the last or the next iframe, and from that, create that specific displayed frame.

So ... first, file sizes are stunningly small, and second, playback within an NLE while applying effects and such can be a right ba^^ard. Hence you must have either an onboard iGPU or specialized long-GOP decoder, or a GPU with specialized long-GOP decoding capabilities.

Intel's KF CPUs do not have that, as all CPUs with F in the name specifically do not include that capability. And only some recent AMD CPUs and mobos built for them have long-GOP capabilities.

Many recent GPUs from Nvidia have this, some don't, most AMD GPUs do not. So you need to know the specifics of the hardware to successfully work with long-GOP media.

I work for/with/teach pro colorists, most of whom have what's referred to in the trade as "heavy iron" computers ... typically 256GB of RAM, maybe a pair of large GPUs when running Resolve, a couple very high-speed SSD filled RAID arrays for 'local' use while working, BM or AJA breakout boxes for the high-end monitors, and all this down the hall in the machine room.

Most colorists hate working with long-GOP, and on receipt from a client, immediately transcode or at least proxy all such media to probably ProRes 422. The file sizes are a lot bigger, BUT ... playback is a lot better. The t-codes are simply dumped when the project is completed as they can be recreated at need and who wants to store extra media?

Using UHD and even higher k-count media that is 10 bit long-GOP is a real processing load for an NLE for simple playback, without throwing in effects. Dump Warp on it, and woa ... that's about the heaviest processing load you can throw at your system.

Even with ProRes stuff, or the BRAW that I work with so much, when I need to Warp something, as soon as it's satisfactory I do a render & replace to ProRes 422, so that stabilization is now 'baked in' to the clip. And doesn't of course require any processing load for playback.

And now I can throw effects at it to my heart's content without slowing my machine. Which is by colorist standards kinda minimalist ... 24 core 3960x Ryzen, 128GB of RAM,  a 2080Ti GPU that I'll update this winter, twin internal Nvme drives one for OS/programs, the other for all cache files. Eight internal SSDs for working drives, a couple large spinners, and network storage down the hall.

Then it is the old laptop you should worry about.......