Decrease memory usage by loading fields more selectively

Just read through the patch and had two comments. Not sure this counts as a "review" ... but hey some feedback is better than none :D

+++ b/modules/customer/commerce_customer.module
@@ -997,9 +997,10 @@ function commerce_customer_field_widget_form(&$form, &$form_state, $field, $inst
-        // First make sure this addressfield is part of the current profile.
-        if (!empty($element['profiles'][$key][$field_name]['#language'])) {
+      foreach (field_info_instances('commerce_customer_profile', $profile->type) as $field_name => $field_instance) {

The original comment here suggested we needed to confirm this addressfield is a current profile. Is this new logic addressing that possibility? Perhaps leaving the comment would not be a bad idea.

+++ b/modules/product_reference/commerce_product_reference.module
@@ -25,70 +25,63 @@ function commerce_product_reference_commerce_product_uri($product) {
-            $extra[$entity_type][$bundle_name]['display']['product:' . $product_extra_field_name] = $product_extra_field;
-          }
+          $extra['node'][$bundle_name]['display']['product:' . $product_extra_field_name] = $product_extra_field;

Are we losing flexibility or is this always going to be a node?

Also, thought I would look at the memory savings. I don't have a fancy way to look at individual function loads and memory usage, but I do have the trusty devel memory stats at the end of the page... We are saving memory here, folks... I setup a Kickstart 2 RC2 instance and patched it with the following patches (and without). Before each page load, I'd clear cache all using drush.

D7 Patch = http://drupal.org/files/field-info-cache-1040790-144-D7.patch
DC Patch = http://drupal.org/files/1809916-decrease-memory-usage-7.patch

You sure about that? I was under the impression it would work for any referencing entity type, though the main use case was node.

Do you suppose this issue is now deprecated by #1960856: Bring Field API Memory improvements from Drupal 7.22 to Drupal Commerce.?

Thanks for already being pro-active about this.

As for @joshmiller remarks in comment #9, if you're looking to get memory statistics on a function level I strongly recommend looking into installing XHPROF, a wonderful PHP performance debugger created by facebook. It gives you memory usage by function and overall. It also gives you other useful information like how many times a function is called, and how much CPU time they all take up. It's the best tool I've found for debugging PHP performance issues.

For those who are interested Drupal 7.22 included some new patches to help solve these issues, but contrib modules need to be updated to take advantage.

#1915646: The Field API's memory usage has been optimized (includes recommended changes to contributed modules to leverage the changes)
"The Field API's memory usage has been optimized (includes recommended changes to contributed modules to leverage the changes)"
http://drupal.org/node/1915646

I've created issues about improving contrib for the changes in 7.22 to other issues queues, like ApacheSolr, Message and CTools. If you're looking for more gains in KickStart I believe Search API, Rules and Inline Entity Form might also benefit from some tweaks.

I think I'm going to hold off committing this for 1.6 in the interest of both:

1. Taking a closer look at the change notice and optimization options and
2. Preventing an update debacle like we had with the update to require Drupal 7.15 (in this case we have a function available only in Drupal 7.22)

Also, I need to get XHPROF going. : )

+  if ($entity_type) {
+    $info = entity_get_info($entity_type);
+    $bundles = array_keys($info['bundles']);
+
+    foreach ($bundles as $bundle) {
+      foreach (field_info_instances($entity_type, $bundle) as $field_name => $instance) {
+        $field = field_info_field($field_name);

^ This looks like a really inefficient way of doing field_info_instances($entity_type) :)

With Drupal 7.24 being a security release, we can now ensure that all users will have the function field_info_field_map(). This was designed as a less memory intensive replacement to field_info_fields(), so if we can use it to avoid calls to field_info_fields() in any given page request, let's do it. : )

https://api.drupal.org/api/drupal/modules%21field%21field.info.inc/funct...

In response to #16 and #17 here's my attempt at a simpler patch. I have not touched hook_update_N() functions as the memory usage there is probably less likely to have an impact.

Thanks! Very timely patch - reviewed and committed.

Re: #16, I checked, and the reason I eschewed field_info_instances() in the past was the lack of field type in the return value. : P

Commit: http://drupalcode.org/project/commerce.git/commitdiff/237c28d

Quick side note: I'm removing the explicit dependence on >= 7.22 in the .info files so sites / tests running from -dev still pass.