Drupal Association members fund grants that make connections all over the world.
I chose Drupal over Wordpress for its functionality and used it to develop a webpage (visible in its nascent form at http://chriswalkerimages.com).
As you can see, the website is unusably slow, both on the production server (GoDaddy shared "deluxe" linux) and localhost (XAMPP, Windows 7, x64, no performance issues).
I am using page caching for anonymous users as well as browser caching, so while the first page request takes > 30 seconds frequently, subsequent requests are completed in an almost-reasonable timeframe. Of course, this does not help load times for registered users.
During development with the Zen theme, I thought the slow speeds were due to the theme registry being rebuilt on every page load. This is not the case: theme registry rebuilding has been disabled in every possibly related .conf file and double-checked in the MySQL tables.
I enabled Xdebug on my localhost and examined the results using kcachegrind: it appears that almost all of the loading time is repeatably due to these php functions:
drupal_load and system_list call drupal_get_filename (~58 times combined).
drupal_get_filename calls drupal_system_listing (~16 times).
drupal_system_listing calls file_scan_directory (~32 times).
Most of the time is spent in file_scan_directory, which is called (including self-calls) ~1184 times.
As far as I can tell, Drupal is scanning many directories every time a page is requested, looking for enabled and bootstrap modules. I believe the module list ought to be cached in an SQL table, but it doesn't appear that this table is being used.
I've deleted all modules I added and disabled all unnecessary modules. This temporarily brought the number of file_scan_directory calls to about ~600, and now it is back up to double that for an unknown reason.
What should I attempt next? Is this a common problem? I can attach example cachegrind files if that would help. Searching indicates that Drupal 7 is generally slow, but this is agonizing and entirely unusable (visitors who don't know about the problem sometimes believe the site is broken and begin clicking links in rapid succession before the server has a chance to serve a single page, then leave the site).