'save_post' action is a common bottleneck

[johnjamesjacoby]

When reviewing code, I see almost daily that the 'save_post' action is used as a catch-all for saving post-meta from inside custom metaboxes. The problem with this approach is that 'save_post' runs even on internal post-types, like revisions, nav-menu items, auto-saves, etc...)

It's my experience that most developers have no idea that their code runs in these circumstances, and they often don't check the post_type of the post being saved, resulting in unnecessary calls to update_post_meta() and sometimes storing useless information in the database.

This issue becomes especially prevalent on sites with complex navigation menus, where sometimes hundreds of calls to 'save_post' can occur. The added overhead of bbPress and a few other CPT based plugins installed can ramp these wasted comparisons up into the thousands very quickly.

Yes... this can largely be considered an education issue. And $post is passed into 'save_post' so it's a simple comparison check to make sure the post_type matches your intentions. There's also transition_post_status that allows even more control.

Knowing this, I think there's still value in addressing this in core, by having a dedicated "save_post_$post_type" action directly after 'save_post'. It's straight-forward, easy to tweak existing code, and provides a simple way to avoid repeated loops through 'save_post' just to compare a post_type and bail a bunch of times.

Patch attached for proof of concept

[tw2113]

Having had to interact with this myself and prevent multiple looping and "loop inception", I would love to see this available.

[johnbillion]

How does 24299.patch​ help with revisions and autosaves? They're post statuses, not post types.

[DrewAPicture]

Seems sensible. +1

[SergeyBiryukov]

Duplicate of #16176.