Active
Project:
Views Tagadelic
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
28 Apr 2010 at 09:43 UTC
Updated:
18 Jul 2010 at 02:23 UTC
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
Comment #1
aron novakJust to note:
Is not so optimal, it's better to include the query used for the views:
Comment #2
indytechcook commentedAaron,
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