user_load() static caching

Would it be easier if modules called user_load as normal, but the user_load function had a static variable that was set if it had already been run and just returned $user?

I agree that this is a problem.

shoudl get fixed in HEAD first.

yes, a static var cache like node_load() seems best. any eaosn not to go that route?

yes, thats what i had in mind.

the only place where we load user info without firing hook_user(load) is during session creation and i agree that that doesn't need to change.

This isn't really needed. By convention, the global $user object is the object loaded by the session handling.

If you need the full user object, do a user_load() and add caching to user_load(). It might cost you 1ms.

update: no progress. user_load() still has no static cache like node_load(). these two issues have worked on it.

right, we should really have added a static cache to user_load in D6 since we now often take a simple int parameter. It was an unfortunate oversight (bug?).

simple (but untested) patch attached that adds such a cache.

typo at the end: if ($cachable)

since db_fetch_object() is defined in the API as returning FALSE for no result, we can also trim a couple lines. fixed typo.

Looks good. We need to reset this cache after a user_save(), no?

yea- good point. Also, we should probably remove the caching code in user_category_load()? Otherwise we are caching the same data twice.

Attached is the patch that I've been using with Drupal 5 for a year or so - it's slightly different because it uses memcache, but should illustrate what needs to be changed.

The main thing to watch out for is modules (buddylist, for example) that write directly to the {users} table without going through user_save - they either need to be rewritten to use user_save for all changes to user objects, or to have a line added that invalidates the user cache when a change is made.

Q: Why do we want to clone a user object before passing it along? If a user object is changed somewhere, we would not need to reload it (again)?

Also, possibly related: #254491: Standardize static caching

Hi,

I hope this progresses as fast as possible, and the fix gets backported to D6.
Right now, not having user_load cache the result causes a lot of trouble.

I am writing a module that uses hook_user() and was wondering why so _many_ queries were being bounced off my DB server. Now I know...

Bye,

Merc.

Yeah, I'm using a panel page (Michelle's APK) adn notice that user_load is being called 11 times on one page, seems like this is gonna be a lot of overhead when the site launches.

Have others found alternative methods? (I see the memcache above)

See #281596: Performance: static caching of user objects in user_load(), respecting conditions.

Went in as part of #347250: Multiple load users

For those of you who are stuck with Drupal 5 and need a simple caching solution I have attached a patch which will get you there, effectively and reliably. It's probably not as robust as the Drupal 7 implementation but it will due for most of the performance needs. It's been tested and used on a production site for a few months with no issues.

NOTE: It also allows you to call user_load() only passing it a numeric value, rather than having to specify the entire array('uid' => X).

Subscribing

Take care when applying patches like this.

Imagine you have a module that adds some data to users:

/**
 * Implementation of hook_user()
 */
function my_module_user($op, &$edit, &$account, $category=NULL) {
  if ($op == 'load') {
    $account->stuff = my_module_load_stuff();
  }
}

/**
 * Save some stuff to user.
 * @param $uid User uid.
 * @param $stuff Stuff
 */
function my_module_save_stuff($uid, $stuff) {
  // ...
  drupal_write_record('my_module_stuff', $item);
  // ...
}

/**
 * Load some user stuff.
 * @param $uid User uid.
 */
function my_module_load_stuff($uid) {
  // ...
  $res =  db_query('SELECT * FROM {my_module_stuff} WHERE uid = %d', $uid);
  // ...
  return $stuff;
}

As modifications are made outside user_save(), you may fall into inconsistencies if you don't explicitly clean the static cache each time you modify user-related data.

I wrote a patch to mantain users in a cache, but I'll definitely revert to the previous version. Safety beats efficiency.

Here's a re-rolled version of pwolanin's patch from #8. Drupal 6.

Note that #23 is not a plug-n-play safe solution. There will be cases where this caching breaks existing functionality and you will have to track them down and use the 2nd parameter to clear the cache.

Regarding the patch in #23, using this at all seems to be "site-breakingly bad" to me, because it improperly changes the first argument, $user_info, to $array, which it used to be in 2008. This value changed a long time ago. It will cause you to not be able to log into your site.

I'm attaching a D6 patch that should accomplish the same with latest versions of Drupal.

There is a mistake in the patch:

<?php
+  $cacheable = FALSE;

+    $cachable = TRUE;

+  if ($cachable) {
?>

The var should be always "cacheable" or "cachable", not a mix :D

Nice catch! Mine would surely generate a PHP notice or something! Thank you!

This is great, even in 2021. Thanks for the patch.

Similarly useful for D6 maintainers repeatedly accessing user profiles in e.g. comment templates is this user_load_profile caching.