drupal_get_filename() does intensive I/O on disk

Here is a sample implementation (that needs work) which would fit to avoid some I/O:

function drupal_get_filename($type, $name, $filename = NULL) {
  // The location of files will not change during the request, so do not use
  // drupal_static().
  static $files = array(), $has_db;

// FIXME: PRI: Useless code.
// Files is an array, no warnings will be throwed by testing non existing
// keys in multiple dimensions. I might be wrong here, please tell.
//  if (!isset($files[$type])) {
//    $files[$type] = array();
//  }

// FIXME: Useless code, a good statically cached piece of data should not be 
// tested over and over again, please do the job only once.
// Plus, file_exists() here will be done next at db introspection phase.
//  if (!empty($filename) && file_exists($filename)) {
//    $files[$type][$name] = $filename;
//  }
//  elseif (isset($files[$type][$name])) {
//    // nothing
//  }
//  else {

  if (!isset($has_db)) {
    if (function_exists('db_query')) {
      // Verify that we have an active database connection, before querying
      // the database. This is required because this function is called both
      // before we have a database connection (i.e. during installation) and
      // when a database connection fails.
      try {
        $result = db_query("SELECT filename, type, name FROM {system}");
        while ($data = $result->fetchObject()) {
          // FIXME: This file_exists() may be skipped using a static cache, and
          // doing this foreach only once at cache build time. Of course, Drupal
          // would not see file system modification then, but file system will
          // never be modified on a production site!
          if (file_exists(DRUPAL_ROOT . '/' . $data->filename)) {
            $files[$data->type][$data->name] = $data->filename;
          }
        }
        $loaded = $has_db = TRUE;
      }
      catch (Exception $e) {
        // The database table may not exist because Drupal is not yet installed,
        // or the database might be down. We have a fallback for this case so we
        // hide the error completely.
        // FIXME: And also, don't let this test happen anymore.
        $has_db = FALSE;
      }
    }
    else {
      $has_db = FALSE;
    }
  }

  // Fallback to searching the filesystem if the database could not find the
  // file or the file returned by the database is not found.
  if (!$has_db && !isset($files[$type][$name])) {
    // We have a consistent directory naming: modules, themes...
    $dir = $type . 's';
    if ($type == 'theme_engine') {
      $dir = 'themes/engines';
      $extension = 'engine';
    }
    elseif ($type == 'theme') {
      $extension = 'info';
    }
    else {
      $extension = $type;
    }

    if (!function_exists('drupal_system_listing')) {
      require_once DRUPAL_ROOT . '/includes/common.inc';
    }
    // Scan the appropriate directories for all files with the requested
    // extension, not just the file we are currently looking for. This
    // prevents unnecessary scans from being repeated when this function is
    // called more than once in the same page request.
    $matches = drupal_system_listing("/\.$extension$/", $dir, 'name', 0);
    foreach ($matches as $matched_name => $file) {
      $files[$type][$matched_name] = $file->uri;
    }
  }

  if (isset($files[$type][$name])) {
    return $files[$type][$name];
  }
}

We should care about all pages performances, everyday admin tasks might be done on a production site.

I'm going to do some more debuging, to ensure there is no other way to trigger this file scan.

The system_list() prime might be documented in the drupal_get_filename() function I think, it would be great for people that read this code.

Ok, so this is a false alert, the behavior I encountered on beta3 seems to have been resolved using RC1. I did some debugging, drupal_get_filename() is being called 84 times on my custom site, most of the calls will set a new file in cache thanks to system_list() function as chx said. There is still 42 calls to file_exists() which is not that bad (but may still be avoided).

We're good.

Why did the bugtracker reopened the bug?.. Reclosing it.