Identify name of update functions without including .install files

At http://drupal.org/node/197720 we identified that Drupal eats considerably more amount of memory on the modules page. This is due to all .install files being included and checked for possible update functions not run yet. Even if the PHP memory limit is made higher, this page might display a WSOD.

The reason .install files are included is to check whether they have newer update functions not yet run on the local database. So the admin is informed that certain modules need their updates run. So we need the list of update functions defined in each module enabled.

A few options to not include the .install file to get this list:

(a) Not serious: introduce a new hook to specify the latest update number. But this would need to be updated by hand, and the info is already in .install files.

(b) Preg through the .install files (so we can load and *unload* them), grepping for update functions. This sounds easy but could have false positives in commented update functions. The only real problem here would be if update functions later then the ones run already are commented out. I'd say his is highly unlikely.

(c) Load in .install files and tokenize them one by one. Then in the tokenized form, we can look up the function definitions. This surely avoids the comment problem from the previous option, but takes considerably more memory, as we would need to have the tokenized source of one .install file in memory at a time. This might end up requiring more memory memory in core itself as the tokenized source takes up more memory is a PHP array then when we include the file and tokenization takes place in PHP's internals (without userspace data access). *But*, we can unset() the file string and the token array, once done with a file, and we can go to the next. This also takes more time most probably then (b).

All these options can decrease the memory requirement for the modules page considerably. Although (c) might not decrease it for core-only installations, it will definitely decrease it for contrib (when lots more install files are loaded, so the fact that we can unload stuff becomes more of an advantage).

Opinions? Anyone up for implementation?