I use tagadelic_view at a large-scale site and i faced with huge performance problems.
I found out that this is the bottleneck:

$result = db_query_range('SELECT COUNT(*) AS count, d.tid, d.name, d.vid FROM {term_data} d INNER JOIN {term_node} n ON d.tid = n.tid WHERE n.nid IN '. $nid_restrictor . $vid_restrictor .' GROUP BY d.tid, d.name, d.vid ORDER BY count DESC', 0, $options['size']);

So i added some lines to template_preprocess_views_view_tagadelic(), at the beginning:

$cache_id = md5($view->name. serialize($options));
  $c = cache_get('tagadelic_preproc_'. $cache_id);
  if (isset($c->data)) {
    $vars['output'] = $c->data;
    return;
  }

And at the end:

cache_set('tagadelic_preproc_'. $cache_id, $vars['output'], 'cache', time()+900);

Maybe it does not fit every use-case, but i think it would be great to add a possiblity to cache this part of the module. I'm ready to create a user-friendly patch (with variables, configurable lifetime) if you agree with the concept.

Comments

aron novak’s picture

Just to note:

$cache_id = md5($view->name. serialize($options));

Is not so optimal, it's better to include the query used for the views:

$cache_id = md5($view->name. serialize($options) . serialize($view->query));
indytechcook’s picture

Aaron,

Performance improvement are always good. Does normal views caching or block level caching help any of this?

What sort of options were you thinking?

Cheers,
Neil