![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 19 years ago
Closed 19 years ago
#5325 closed defect (bug) (fixed)
sanitize_post and sanitize_post_field are very expensive no-ops
| Reported by: | Quandary | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.3.2 |
| Component: | Optimization | Version: | 2.3.1 |
| Severity: | major | Keywords: | has-patch |
| Cc: | Focuses: |
Description
Simple, commonly-called template functions (the_title, get_permalink, etc.) are all channeled through the get_post function. While get_post implements caching, it caches content before it's been filtered, not after. This means that sanitize_post is called for each and every call to get_post.
I loaded a test page 5 times in a test configuration that had 86 calls to get_post (mostly via get_the_title and get_permalink). Instrumentation results from APD indicate that fully 8-15% (~9.5% avg.) of the page generation time was spent in sanitize_post and sanitize_post_field, even though nearly all of the calls were for "raw" data, and no filtering was actually taking place. I added a simple early bail-out to bypass the no-op actions, and this reduced the hit to .1-.2% across another 5 page loads (no, that's not a typo ;).
I'm attaching a patch to fix this bug, but this is only the immediate problem (get_post appears to be called with "raw" way more frequently then with "display"). Opening another bug on the filtering implementation may be warranted.
Be almost two orders of magnitude faster at doing nothing.