Poorly Coded – Stay Away

@reedus33 – Posting the same reply I did to your thread comments.

Sorry to hear that. Not gonna say there aren’t potential bottle necks, but often our plugin isn’t the problem, more often a symptom you see from a larger issue, such as bulk use of uncached WP_Query or WP_Term_Query, which of course we have to filter properly or users would report it doesn’t work correctly.

First to touch on code quality, bar none you will not find many with higher code quality in the repo. 15 year veteran WP developer with nearly 1 Million active users. We fully implement WordPress Coding Standards on every commit, as well as PHP Static analysis (phpstan lvl 6), and the plugin’s JavaScript fully typed TypeScript, . I’d wager 80% of plugins on the repo wouldn’t pass WPCS checks alone, and 99% wouldn’t get past phpstan lvl 1). That would include major plugins like WooCommerce, CF7, Ninja Forms, & even Gutenberg.

That said, as I touch on details below consider this, every piece of content rendered on the screen is effectively checked to make sure the user has permission. We try to optimize this, and since v2.0 we have made performance enhancements in every version. Second the only feedback we have at large scales is our own and what you see here in the forums. This thread and one from a week prior are the first “performance” issue threads ever submitted.

Next we also do New Relic monitoring on very large live sites using these same plugins, rarely do CC functions/actions come up in the top 20 slowest calls, reiterating that its likely a compounding of simply having a ton of stuff that might or might not be restricted on a given page. The 2.4.0 updates likely should help drastically if you have a large scale & high traffic site.

v2.4.0 which went out today, was tested extensively with PHP XDebug Profiling, pretty much can’t be reduced any more than that while still providing actual live & real time restriction at the granular level we provide.

1. v2.4.0 already addressed many potential bottlenecks, primarily just more static caching of function calls. A function can be well optimized and take 0.1ms to run, but if you call that function 500 times across a page load checking every post/term/title it stacks up. Static caching in v2.4.0 saves the calculated value where possible and keeps returning it. So now those 500 calls can take pretty much 0.0ms to complete.
2. Along with v2.4.0 of the free version, the pro version offers object caching in a new update coming.

In reality during local host testing, v2.4.0 with CC Pro object caching (using simple file based caching), the page loads were within +/- 1% of without the plugin active, often leaning towards -2% showing it was actually faster than without the plugin active. Not sure I believe that last part but its what the tests showed. The tests were done with term queries on 5 different custom taxonomies, rendered using repeating set of term clouds. In all 25 term clouds, 5 of each.

• Without CC, this page took ~50ms to load.
• With CC v2.3.0, the page took ~130ms to load.
• With v2.4.0 core only, the page took ~60ms to load.
• With v2.4.0 + Pro with Object caching, page load was 45-55ms.

That said there are complex issues that can create weirdness within WP and querying. We do our best to support anything done “The WordPress Way” out of the box, beyond that we’d need to investigate that specific issue.

If your still having issues after v2.4.0, you should really open a dedicated ticket with your full details anyways, performance issues are rarely gonna be 1 size fits all, for example I can’t assume your all on the same host, using same browsers, same apache stack, same plugins & custom code etc. So each should be its own thread unless you are certain the issue is the same.

Hope that helps.

• This reply was modified 5 months ago by Daniel Iser.