What's Content Taxonomy's performance overhead?

it depends on how you are using the fields. if you do not save the terms additionally to the term_node table, it's very fast. I even would say, with many fields, nodes and terms it's more efficient than the core taxonomy system. the core taxonomy system stores every term assigned to a node in the same table, which can get quite huge and might slow things down. Content Taxonomy has it's own separate table for each field, which are normally smaller than the term_node table. Nevertheless, you want see any significant performance difference, except of extreme usage of the taxonomy system.
Content Taxonomy fields will probably have the same performance as any other CCK field.
The most important thing for the performance of your site will be the right configuration of caches....

Hello,

I was just checking out the data structure, and it seems Content Taxonomy only saves the term id in the content type table, not the actual term.

The term is still saved in term_data table, hence a join is needed to get the actual term through the termid.

I was under the impression Content Taxonomy handles everything in the content type table...

Even if I uncheck "Save values additionally to the core taxonomy system (into the 'term_node' table)." this is the case.

Any ideas?

Why do we need to rely on the taxonomy term_data table at all?

@giorgio79: This way if you change the term name the nodes are updated as well.
The values of both term id and name are then stored in the cache and can be called from $node and node_load().
For example, the whole term lineage can be accessed in contemplate like this:

$node->field_model (array)

    $node->field_model[0] (array)

        $node->field_model[0]['value'] 
            5 
        $node->field_model[0]['view']
            Some Product

    $node->field_model[1] (array)

        $node->field_model[1]['value'] 
            4 
        $node->field_model[1]['view']
            Some Model

    $node->field_model[2] (array)

        $node->field_model[2]['value'] 
            3 
        $node->field_model[2]['view']
            Some Brand

Themed views also benefit from node_load to display the field as it have better performance than directly from the views queries.

Also note that while reading nodes is fast, writing nodes may not be, so saving node terms to cck but not saving to term_nodes would be the best option.

Thanks Agustin.

I understand this but you are addressing only the php functions, while I am addressing the mysql data structure.

Given the module name, I assumed everything is finally stored in CCK tables.

I dont see the point of needing to use the taxonomy term_data table at all, since the term name could easily be stored in the content type table together with the term id.

This is much much faster for MySQL if the id and the term itself is in the same table.

Sure, you wont notice the current setup's shortcoming if you only have a few hundred words in your vocab, but a free tagging vocab for a larger site can easily reach thousands, and there, avoiding joins is essential.

I still don't agree that only the term id is stored in CCK, and not the term data. (that is the term name...)

Functions can be written, and modified, but not the tables once you get going with it, hence I dont consider the current setup an ideal data structure.

In that case it will be a welcome addition, this is a feature worth its own issue.
The handling of the table may be implemented within a submodule.

Please open a new issue if problem still exists.