The performance of debug_backtrace [#1466096]

In the clear function, i see it using the debug_backtrace for detect something related to cache_clear_all().
I don't really understand the purpose of this detection. But as what I figure out, I propose replace the original code:

function clear($cid = NULL, $wildcard = FALSE) {
  // It is not possible to detect a cache_clear_all() call other than looking
  // at the backtrace unless http://drupal.org/node/81461 is added.
  $backtrace = debug_backtrace();
  if ($cid == MEMCACHE_CONTENT_CLEAR || (isset($backtrace[2]) && $backtrace[2]['function'] == 'cache_clear_all' && empty($backtrace[2]['args']))) {
				// Update the timestamp of the last global flushing of this table.  When

with the following code:

function clear($cid = NULL, $wildcard = FALSE) {

  // It is not possible to detect a cache_clear_all() call other than looking
  // at the backtrace unless http://drupal.org/node/81461 is added.

  if ($cid == MEMCACHE_CONTENT_CLEAR ||  (NULL === $cid && in_array($this->bin, array('cache_page', 'cache_block')))) {
  // Update the timestamp of the last global flushing of this table.  When

Comments

Comment #1

berdir

German

Switzerland

commented 10 March 2012 at 17:05

Status:

Needs review

» Active

The problem is that the following two calls are *not* the same thing for memcache:

cache_clear_all()
// vs.
cache_clear_all(NULL, 'cache_block');

While it's treated the same way for the default database cache, memcache purposely behaves differently, as it's not necessary to clear out stale data, as opposed to the database.

The debug_backtrace() is an ugly hack, but it's the only possible way. This won't be necessary anymore in D8 as cache_clear_all() is on it's way to being killed.

The tests should actually fail with your change, have you tried that?