Every admin page load checks for updates.

yes, xdebug shows it using a ton of resources,

IT is the _cvs_deploy_find_latest_update() function that is taking up 30% of the load time is this function, according to xdebug. I have quite a few modules, so this is probably more pronounced. I think the solution is to provide some sort of caching here inside this function.

function _cvs_deploy_find_latest_update($dir, $timestamp) {
  if (is_dir($dir)) {
    $fp = opendir($dir);
    while (FALSE !== ($file = readdir($fp))) {
      if ($file == '.' || $file == '..') {
        continue;
      }
      if ($file == 'CVS' && is_dir("$dir/CVS")) {
        $entries_file = $dir .'/CVS/Entries';
        if (file_exists($entries_file)) {
          $mtime = filemtime($entries_file);
          $timestamp = ($mtime > $timestamp) ? $mtime : $timestamp;
        }
      }
      elseif (is_dir("$dir/$file")) {
        $timestamp = _cvs_deploy_find_latest_update("$dir/$file", $timestamp);
      }
    }
    closedir($fp);
  }
  return $timestamp;
}

Hi there, I just want to chip in on this topic with some (very unscientific) numbers. I'd like to note that this problem is exacerbated when one's DocumentRoot is on an NFS server - every trip to disk becomes much slower.

Loading admin/build/modules without cvs deploy enabled, but with about 10 other modules enabled (our standard complement) makes about 70k lstat64 calls (by far the most used system call according to strace).

Enabling cvs_deploy bumps that number to 430k. (over 6x greater!) When open_basedir is configured for that vhost, the number of calls jumps to 1.3 million - this obviously isn't CVS deploy's fault, but it sure hurts performance in a bad way...

I'm not familiar with the cvs deploy code base, and I imagine it might also take some changes to core, but I'm hoping to get the ball rolling on some discussion as to what can be done to improve the situation. I would also be willing to work on a patch, if pointed in the right direction...

As a reference, my drive that druapl was running off was ntfs, with ntfs-3g install on ubuntu 8.04. It may be that this slowed down performance as well. I'm changing that config now and will report back if ext3 changed load times.

I'm 99% positive this is caused by #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc. Once that's fixed, this won't be a problem.