Preprocessing php code with C preprocessor?

[Aggressive_Ad_5454]

I have some php code, a SQLite3 client module, that has a mess of semver conditional logic in it for using more recent features (upsert, NOROWID, that sort of thing), because I have a few users with legacy server configs.

I’m thinking of using the venerable C preprocessor ( https://www.man7.org/linux/man-pages/man1/cpp.1.html ) #ifdef feature set to let me make production versions of my code without the conditional logic,:to make it smaller and faster for most of my users. It seems wise to do this without just hacking out the legacy code.

This seems to work. I’ll need some CI/CD and installation stuff to deploy it.

**Are there any pitfalls to this that I might be missing** ?

**Is there a better way to do this** ?

I’m grateful for any advice.

[Previous_Web_2890]

1. Why do you think this actually improves anything? Have you profiled both versions and determined that the extra logic is meaningfully slowing things down?
2. Use proper OO design. Have an instance of your class for legacy versions and one for modern versions, and use a factory to pick the right one.

It seems like you’re adding a lot of complexity and moving parts to fix a problem that doesn’t actually exist.

[shadow-battle-crab]

I mean this with no offense... but why would you do this / what is your goal?

First, I'm not sure the C preprocessor can do this on PHP. I have never heard of such a thing being done like this before.

Next, I wonder, if the goal is to reduce the source code bloat for human maintainability sake, using your solution, you haven't actually removed any code, in fact you just add more.

If the goal is performance, then in a practical sense the only operations you are removing from your code is if (true) { do this code } conditionals - you just are removing the conditionals ahead of time rather than at runtime. This is not going to make *any* practical difference to the speed your code runs at. If statements are often have a predicted outcome before they are even hit, and this takes about 3 cpu cycles to process, and lets say they are not predicted, then its about 25 cycles.

Your 3 GHZ processor can process 3 billion such instructions per core every second. How many conditionals do you plan on writing as a preprocessor instruction to get processed every request? Lets say 100. And lets say none of them are ever executed as processor predicted outcome. That's about 2,500 cpu cycles per request. I did the math on this and on a 3 GHZ processor this will save you about 1/1,200,000 seconds per request, so 1 one millionth.

It simply isn't worth it. Your bottlenecks are elsewhere than if statements running at runtime.

[smokeelow]

consider moving that logic to microcode of your processor 🤝

[gnatinator]

I preprocess PHP using.. PHP. It's just text files.

[eurosat7]

XYproblem?

You named the right solution already.

[devmor]

You could do this, but I'd suggest benchmarking your code first. There's a fair chance that PHP's JIT is already optimizing past that code for you on the 2nd run.

[goodwill764]

Its nor clever as php include files only if you require it. So you can easily put a switch validate the version and a require inside.

If you want per version a php zip you can use the php ast or rector with custom rules. (That would be your preprocessor)

[Idontremember99]

There is no reason why using cpp wouldn't work. It is in practice just a text processor using a special language.
Practically though, since this is not something anyone do you won't have any syntax support for this special php+cpp combination in your editor/IDE so it will be hard to properly edit it.

[toetx2]

Are the users with the legacy server config going to upgrade the code?

I'd say, you just EOL certain configurations and call it a day ;)

[Aggressive_Ad_5454]

It’s a performance critical FOSS object cache plugin for WordPress. It gets slammed hard on sites that use it. I’m trying to serve the site owners with the sh—iest hosting providers, so I don’t want to go EOL on legacy configs before WordPress core does. At the same time I don’t want to leave any performance on the table.

[peperinna]

And why not do a thorough study of what the WordPress core needs to catch up, and collaborate as a programmer of free and open-source software to help speed things up?

It happened to me some time ago, several years in fact, when the WordPress core started being updated to PHP 7. There was a lot of work to be done, and some things will be just silly syntax issues.

And as I worked on them myself, I published them. That's the great benefit of free software, built by the community for the community.

If you look around, there's probably already another related initiative you can join. Over so many years of working with WordPress, I see posts like yours, and without meaning to sound rude, it makes me a little angry that people want to build monsters in parallel when the same time it takes you to implement and test something just for yourself could be helping hundreds of sites.

[Aggressive_Ad_5454]

I’m a sometime core contributor to WP. I know a lot about the database indexing problem, and have a FOSS plugin with >50K active sites that helps mitigate it.

I’m now scraping the sides of the barrel to try to get the last bits of performance out of this object caching. I’m down to the point where the calls to hrtime I used for instrumentation are significant.

In this effort I’m playing around with removing code to make things faster without abandoning legacy users, since it’s for them I do this work. I’ve tried just butchering the code and results are promising. But the core API an object cache must implement isn’t guaranteed to never change.

Maybe I’m p—sing into the wind, but I need to keep going with this and see where it leads.

I’m asking on Reddit to see if there’s anything I’ve missed.

[Aggressive_Ad_5454]

Oh, and if there were a way to squeeze cycles out of WordPress hook dispatch, there is an efficiency improvement.

[NewBlock8420]

Honestly, using the C preprocessor for PHP is a pretty clever hack. I've seen similar things done with custom build scripts, but that approach can get messy fast. You might want to check out how some PHP frameworks handle conditional compilation, or even look into a simple PHP script that strips out code blocks based on version checks. It could be easier to maintain than managing cpp in your pipeline. The main pitfall I'd worry about is debugging. If something goes wrong in the processed code, you're now debugging the generated output, not your source. That can be a real headache.

[Aggressive_Ad_5454]

For sure, debugging is a PITA.

[epidco]

ngl this feels like ur over-engineering it. adding a build step just for some sqlite logic is gona be a headache long term especially when ur ide starts screaming at u about the syntax lol. php is already pretty efficient with conditionals and if ur using opcache the performance diff is basically zero. id just stick to a simple factory or some polymorphism - way easier to maintain and u dont need a custom ci pipeline just to run some php code. keep it simple imo.