Re: Feedback requested on using #defines to improve the performance of the TSRMG macro

Arvind Srinivasan wrote:

Does the GLOBALS_ID_BASE idea work? In "ts_allocate_reserved_id(GLOBALS_ID_BASE+1...)" each extension would anyway need to reserve an increment to avoid clashes. Also, why is

I didn't really try using this. When I added it, I thought it might be useful for modules that live outside the PHP source tree. They could then define their constants using #define FOO_ID (GLOBALS_ID_BASE + 3) rather than hardcoding 33. As you point out, they would still need to reserve an increment.

GLOBALS_ID_BASE 30 when the largest reserved value is 18? Maybe I'm missing something.

I reserved IDs for the subsystems I thought were core. I was sure there'd be others that I'd missed and so I left space for more.

Would there be significant memory space or locality issues if one ID per extension in the PHP source bundle was reserved upfront, even if those extensions were never enabled?

I'll run some tests and see what impact this has.

I'd vote that the reserved slots be assigned from day 1 for one of (i) always-enabled core extensions or (ii) for core + common extensions or {iii} the whole set of PHP-bundled extensions + common extensions from PECL (i.e. APC?). The choice of (i), (ii) or (iii) would depend on your tests. All other extensions should use a run-time allocated non-reserved slot. Extensions that become popular can add an xxx_GLOBALS_ID entry to zend_globals_macros.h. Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd