install_profile_info() does a file system scan on every request to admin/config (and etc.)

+++ .htaccess	4 Jan 2011 06:18:20 -0000
@@ -2,6 +2,10 @@
+php_value auto_prepend_file /usr/share/php/xhprof_includes/header.php

Well, leave this out, of course.

Edit: Nevermind... you beat me to it.

This one's a bit simpler :)

I don't think micro optimization during the installer is super important. Also, doesn't require an API change.

Let's try this one then, here we also optimize system_modules().

This patch gets more to the source of the problem: drupal_required_modules() does a full .info scan, which trickles down to any function that uses install_profile_info(). This patch is more API friendly and less hacky.

The test failure in @carlos8f's patch looks like it's actually just due to a simple bug in the patch, which is easy to fix. The previous code guaranteed that drupal_required_modules() always returned the install profile as its first array element, but the new code doesn't. So when install_profile_info() calls array_shift() on it, it winds up removing the wrong element from the array. We could definitely fix the code in the patch so as to keep that assumption valid.

However, I guess there is still one API-affecting thing in the patch; by getting the info file dependencies from the database rather than always scanning the filesystem, it means that if you use hook_system_info_alter() to affect the 'required' status, that will now start affecting the return value of drupal_required_modules() too, but only post-installation. That's not necessarily wrong (in fact, it might really be a bugfix on its own), but it is a bit of a change.

So overall I think @carlos8f's approach is preferable, but if we're worried about that for D7 then the patch in #9 is good too. However, with this code:

+  $profile_info = system_get_info('module', drupal_get_profile()) + array('distribution_name' => 'Drupal');

I think it's really ugly to have the calling code responsible for that. Could we add some code to _system_rebuild_module_data() to ensure that the default 'distribution_name' = 'Drupal' winds up stored in the {system} table for profiles that don't specify their own? (OK, one could argue that's an API change too, but I think the argument would be pushing it.) There's already lots of special-case code in _system_rebuild_module_data() to handle the install profile's .info file, so adding one more there seems much better than having the calling code do it.

Let's go with this one for now, since it's safest. We could always do the other approach in #1029390: No API function for getting install profile info without a full file directory scan and possibly backport it.

The new code comments in #13 had some typos, so I rerolled to fix those.

I also realized that in the case of drupal_install_profile_distribution_name(), it already has separate code paths for the installer and everything else, so why not just fix the performance issue internally to that function and not have to change the calling code? That seemed better to me, so I made that change in the attached patch also.

This looked fine to me otherwise and testing it out with custom distribution names everything seemed to work fine. So feel free to RTBC if the new changes look good to you.

http://drupal.org/cvs?commit=502220

BTW, found a related issue, #1081266: Avoid re-scanning module directory when a filename or a module is missing: file_scan_directory() is called for each missing module or install profile, this was continuing to slow down admin/config for me.

This has introduced PHP Notices, as there is data being added to install_profile_info() that doesn't get added in system_get_info.

Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of includes/install.inc).

Hmm, the patch itself looks like it accounts for this though. I'm going to put back to fixed, as this was actually something rfay ran into, so I can't replicate it.