Some field functions are called a bit too often.

sounds like a good idea.

waiting for testbot.

Patch looks great, will RTBC once test bot is green.

+1 on the principle.
Though, to avoid calling a supposedly internal _field_info_collate_fields() function, may I suggest creating a new

function field_info_fields_by_id($field_id) {
  $info = _field_info_collate_fields();
  return $info['fields'];
}

function - we'd have field_info_field(), field_info_fields(), field_info_field_by_id(), field_info_fields_by_id(), would only make sense IMO.

re @chx : right, quick copy / paste error :-).

+1 for RTBC - Although, while you're at it, don't you want to replace the occurrences of foreach() {field_info_field_by_id():} in field_sql_storage.module ? (if so, the change should be mirrored in field.api.php, since the code for the storage is taken out of field_sql_storage)

I guess there's a balance between the gain (reducing overhead of - snappy - function calls) and the cost (creating a temp copy of the array listing all fields)

"Not sure what API change you are talking of, really"

I'm not talking about any API change - I mean that the code for hook_field_storage_load() in field.api.php is taken from field_sql_storage_field_storage_load().
Strictly speaking (and to encourage the use of the newly added field_info_fields_by_id() instead of repeated calls to field_info_field_by_id()), if field_sql_storage_field_storage_load() changes, the code example in hook_field_storage_load() should be updated too.

Patch is the same as #11, which I RTBC, plus updates the sample code in field.api.php

Thus, RTBC.

Doh @ git diff --no-prefix

Does this result into a measurable performance improvement? Although this API addition make sense, it would still be good to know.

No need to create a 'freak install'. Thanks for your explanation though. I'll have another look at the patch. :)

LOL @ freak install. That's my new favourite phrase.

Committed to CVS HEAD. Thanks.