1

From highest rated answer of this post (Drupal 6 case): Does having too many content types negatively affect site speed and performance?

It is said that:

Sharing fields among the content types does affect the performance.

But when creating new content type in Drupal 7, the body field will be pre-populated. When many content types created, if not deleted, this field will be shared among all content types.

This is the body field as seen in admin/reports/fields: enter image description here

The question is, does it affect performance? and what is the best to do for performance? Do I need to delete the pre-populated body?

2 Answers 2

2

tl;dr: No.

What happened in D6 when you shared a field, was that it got moved to it's own table. This became irrelevant with D7, as all fields are now stored in separate tables, which was a very controversial decision, due to the performance effects this has.

If you want to increase performance, you can read some more here: How do you improve drupal performance.

2
  • You were like 5 seconds faster, I'm writing too slow ;). FYI: While it was a controversial decision initially, nothing else would work with the way fields work currently (Hint: fields are per language, imagine what adding a language would do). This can be seen nicely on the Per-Bundle Storage project (drupal.org/project/pbs), which is dead :). Read performance has been improved thanks to the field cache and entitycache.module (which results in a way better situation than D6 ever was). Write performance is still a problem of course, one possible solution there is MongoDB...
    – Berdir
    Commented Mar 10, 2012 at 15:56
  • Heh, you snooze you loose ;) Thanks for adding more info. :)
    – Letharion
    Commented Mar 10, 2012 at 21:26
2

The Drupal 7 fields module is a complete rewrite of CCK, it's of course strongly influenced by it but differs in many aspects.

One of those aspects is that Drupal 7 fields always behave like shared fields in Drupal 6. Meaning, every field gets it's own table (two, in fact, one for revisions).

So what this is means is that there is no negative effect for performance for shared fields. The opposite actually, shared fields means less database tables and less metadata to keep in memory (The configuration of every single field of the complete installation is kept in a single cache, this behavior is currently being improved here).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.