wordmove VS bootsnap

If you are comfortable using a terminal i would recommend wordmove. Setting it up can be tricky but after that its probably the fastest way to sync websites.

If it's a bigger website then I will use two stacks. Same docker-compose code, different environment variables. One stack will be on my production server, and the other will be on my development server. They are the same stack since the stack only defines the infrastructure, not the code, so you can use the same code for two different environments. All mounted volumes (mysql, wordpress cms files, media, plugins, etc) are ignored in my git repos. I use Wordmove to transfer files and data between environments. It has push/pull capabilities and will automatically change your permalinks for you, so you can pull data from your production environment into development, or you can push development data to production. Very useful.

Check out Wordmove. Provided you have SSH access to the remote server it'll handle transferring everything pretty seamlessly, including replacing domain names between environments. Check the repo's Wiki for a wealth of info. To avoid problems with the Local app make sure you're using the same PHP binary (in Local's site list, right click -> Open Site Shell)

Just use WordMove : https://github.com/welaika/wordmove

Indeed, I did not mention Bootsnap so as to detract the core point.

> That's one of the things Bootsnap does to speedup boot time. And when you do that, there's no compilation at runtime.

Correct, if one does `bootsnap precompile`.

Bootsnap hooks itself on `Kernel#load` + `Kernel#require` and `RubyVM::InstructionSequence#load_iseq`:

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

Essentially this means that it makes LOAD_PATH lookup faster + intercepts iseq compilation to store to cache on a miss and return a cached version on a hit.

That does not change the load order.

> But that doesn't change anything about OP's suggestion, it's still impossible to know if an interface will ever be implemented.

Again correct, as even with `bootsnap precompile` it would only result in earlier ISeq generation (it is essentially cache priming instead of doing it "lazily" on demand), not the time at which these ISeq get loaded and effective, so even then an `abstract` keyword would be ineffective.

I always had mixed feelings about writing native Ruby extensions. They surely are the way to make critical parts of the code run faster, but the developer experience around that was not great for a Ruby programmer like me. Sure, I know C. This was the second language I learned (after Pascal). I can write C, I can read C, and I even wrote some larger extensions in it, but I never felt comfortable with it.

To alleviate this problem, the engineers at Shopify created bootsnap, a gem which automatically detects and caches exact load paths to make those require calls fast (see Bootsnap: Optimizing Ruby App Boot Time for details).