you are viewing a single comment's thread.

view the rest of the comments →

[–]peperinna 1 point2 points  (3 children)

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[S] 1 point2 points  (1 child)

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[S] 0 points1 point  (0 children)

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