When I got started using Drupal 7, I added several fields to my site using the Computed Field module (to calculate age, zodiac sign, and so on).

Now that I have been using Drupal 7 for a few years, I realize that it is generally not a great practice to write PHP code in the UI, as the Computed Field module requires. But, the code I am using has worked for the past few years, so that is no longer an issue.

However, I am wondering if there is a significant performance difference between using the Computed Field module (saving the result in the DB) vs. running the PHP in hook_node_presave() or in a similar fashion somewhere in a custom module.

Would removing my computed fields (and uninstalling the Computed Field module) and replacing them with fields in a custom module significantly increase performance?

4 Answers 4


I have used the computed field module a few years ago, and immediately started to "not" use it.

  • In most cases, data that goes into computed fields do not need to be stored at all. They are often simpler calculations. Storing then and their retrieval cost can easily go more than the time it takes to calculate them.

  • Performance difference between an eval()d code and code in a file, I wouldn't call it significant. But in best practices perspective, a custom module is significantly better.

  • If you update your Drupal core version between major versions, chances are that you will need to update the code anyway, because Computer Field cannot migrate the PHP code for you.

  • In most cases, you wouldn't even have to save data in your custom module. hook_node_view would be a great candidate because you have your full node objects there, and you can easily modify a lot of things. Extra field hooks can be useful as well. As you can see, a custom module can have different approaches.

Bottom line, I would go ahead and put the code to a custom module.


"Significant" really depends on too many things - how often such nodes are created, how many users (anon/auth) does your website have, which other modules you have installed, what's your workflow setup (e.g. Rules, moderation modules, etc.) and so on.

While doing this through your code is definitely going to be faster, I doubt you will really notice performance improvements. Doing things in code will in most cases have lower overhead than installing a module to do the same.
If you're really wondering about exact performance differences, you will have to benchmark it with Devel and xdebug for example.

However, you already mentioned another important point - it's generally not a good practice to have raw PHP code entered anywhere in admin. Sometimes it's faster to do it (e.g. in Rules, Views or other contrib modules), but over time you should look to migrate those changes to code. Not to mention that you will reduce the number of modules on your website, which is generally a good thing.


There is a performance difference - code entered through the UI is executed by running through PHP's eval() function. Code run through eval() cannot be cached via APC or OpCache, so it naturally runs slower than corresponding code in a module.

However, ultimately this likely won't be a huge difference performance-wise if you aren't creating and updating nodes too often. However, it is generally not best practice, and makes it impossible to apply change management / version control processes to that code.


If you're interested in a possible alternative for the Computed Field module, which doesn't require the PHP filter to be enabled, then have a look at the Math field module as another alternative.

Refer to my answer to "How to use Computed_field as a product of an existing one?" for way more details on that.

  • In Drupal 7 at least, Computed Field does not depend on the PHP Filter. I have the PHP Filter disabled but Computed Field still works. Commented Mar 11, 2016 at 1:10

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.