Optimize drupal_static(): we shouldn't sacrifice simpletest coverage for performance and vice versa

Attached is my proposed solution. It changes drupal_static() to save its data in a global variable. According to @sun in http://drupal.org/node/601806#comment-2212386, this has been shot down in #254491: Standardize static caching, but I skimmed through that issue and couldn't find the arguments against it. This patch still maintains the drupal_static() interface for writing to the variable. But for reading, it allows the existing interface to be used OR the more direct way of checking a global variable for functions that need to be fast. My thought is that we need something like this, or else we need to clarify when non-resettable statics are okay, and where they're not, and then we need to be okay with the performance hit of resettables, and not refuse important patches because of that performance impact.

I'm attaching a micro-benchmarking script. Here's what I got on my computer (times are in micro-seconds per invocation, averaged over a lot):

        url()  theme_markup()   theme('markup')   drupal_render(#markup)   drupal_render(#type=markup)
HEAD    35.4   12.4             21.9              46.7                     53.3
Patch   36.1   12.4             21.6              46.6                     49.1

The patch introduces virtually no performance impact to url(), while making the alter() step re-settable, and the patch removes most of the performance difference between a drupal_render() of an element without a type vs. one with a type, while maintaining resettability, hopefully, clearing the path to #601806: drupal_render() should not set default element properties when #type is not known being solved in a way that works for everyone.

How about this one, bot?

I can't replicate the invalid syntax error locally, but perhaps some weird invisible mac character made its way into the file. Trying again.

@moshe: while PHP won't let us enforce this, my recommendation is to always use the drupal_static() function for writing to the variable (or retrieving a reference for writing to it), and to continue to use the drupal_static_reset() function for resetting. The only change would be to allow a few functions which get called very often to be able to read directly from the global. Please see patch for the code details on this. Does this work for you, or does the lack of PHP's ability to prevent direct writing to the global make this a no-go for you?

@moshe: I want to take your gut reaction seriously. Does #619666: Make performance-critical usage of drupal_static() grokkable work for you (either the original patch or #6)? Either one would need further refinement, but the key thing being that the return of drupal_static() being something that can itself be persisted and guaranteed to revert to NULL after a call to drupal_static_reset(). If that seems less prone to contrib devs running amuck, I'll happily mark this issue a duplicate, and let community effort focus on that one instead.

We can simplify #619666: Make performance-critical usage of drupal_static() grokkable if that's what people want. I'm sold on a global being more easily abused than the solution in that issue. Therefore, marking this as duplicate.