It should be possible to disable forced flushing of derived images.

image_path_flush() clears any cached versions of a specific file in all image styles. It doesn't flush cached media for an entire style like image_style_flush(), so it actually provides a sort of performance benefit (since you don't have to flush an entire style cache/the entire image cache to see any changes).

Disabling this would cause confusion to users if they used the "file replace" functionality to replace an existing image with a new image but the old image continued to be displayed throughout the website. A similar issue has already been brought up over browser caching of images #1701924: Add a cache-busting string to images.

Do you have a use case for disabling per-file image style cache flushing? :)

Maybe we should more intelligently perform image_path_flush if $file->filesize != $file->original->filesize, which means the file *actually* changed.

Actually might be nice to have a utility function to use here:

file_entity_has_file_changed($file, $original) {
return $file->filesize != $original->filesize || $file->uri != $original->uri;
}

syntax error, sigh

This saves 4 seconds on save with amazons3 module :)

Just rerolled the patch for testing.

As I just rerolled the patch, I set it RTBC. Btw it works well.

This issue is major/critical if remote stream wrapper is used.

In our case when saving a node with 10-15 uploaded image. On the node form thumbnail image style is generated, then click on save, the generated images are flushed, however the only change of file is status to 1 at this point. Which means 20-30 api calls to amazons3.

Profiler said the 90% of runtime is file_entity_file_update. It's easy to run out of resources.

+++ b/file_entity.pages.inc
@@ -443,6 +443,8 @@ function file_entity_add_upload_submit($form, &$form_state) {
+      $file->file_entity_skip_image_flush = TRUE;

I think we could skip this entirely if we check if empty($file->is_new))= in file_entity_has_file_changed().

This patch is excellent, really saved my neck when I was working with RESTWS requests and finding that a simple PUT request to a file would take longer than five minutes to finish up. Reiterating @szantog's statement about it being essential when used with remote_stream_wrapper.

I've rerolled it against the latest DEV, with @Dave Reid's suggested change. I kept the check against $file->file_entity_skip_image_flush so one of our custom modules could fiddle it under the right circumstances.

Looks like a good change, thanks for the re-roll and reporting.