This can be tested by adding some print memory_get_usage statements to cache_setting() and doing a "drush cc all". There are 2 issues in this routine:

1) Calling views_get_view with the last argument TRUE causes the entire view to be loaded. This argument should be FALSE. True, it might return the block cache setting of the previously cached view, but that's pretty rare compared to the cost of loading the entire view again.

2) Calling set_display also causes Views to use lots of memory. Instead, the supplied patch (given below) shows how to loop through the displays and find the block_cache option.

CommentFileSizeAuthor
#2 fix-cache-1287880-2.patch908 bytesmpotter
#1 fix-cache-1287880-1.patch851 bytesmpotter

Comments

mpotter’s picture

mpotter commented
StatusFileSize
new fix-cache-1287880-1.patch851 bytes

Here is the patch for the above issues.

mpotter’s picture

mpotter commented
StatusFileSize
new fix-cache-1287880-2.patch908 bytes

Actually, here is an improved patch that fixes a error when the cache setting cannot be found.

tirdadc’s picture

tirdadc commented
Assigned: Unassigned » tirdadc
Status: Active » Fixed

Much, much better. Tested this and it makes a tremendous difference. It's committed now and in the beta5 release, thanks again!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.