Posted by carn1x on October 5, 2011 at 4:29pm
I've come into a Pressflow 6 site that needs speeding up, and has a fair amount of PHP Input Format usage for things like Views Arguments and on various blocks in order to provide simple things like base_path(). In my hunt to shave time off of page load times, is it worth much effort to try and move all PHP Input Format code into custom modules?
Comments
If your motivations are
If your motivations are strictly for performance then it's probably not worth it. However these are a real pain in the ass to maintain. I would suggest that each time you need to make a change to something that uses the PHP input format then move that into a module somewhere instead.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Well, eval is slow, can be insecure and difficult to maintain
Well, you should consider that run PHP in a eval() call will be more slow, much more. PHP Input Format may represent a security risk when you do not care about sanitize some variables, and its dificult to maintain.
So, i prefer to use PHP Input Format ONLY in very very specific cases, in non-online projects (like intranets). When its online, try to not use it with maximum effort, and you'll have more time to more important thinks at weekends, like drink a beer instead to stay looking for improvements for your Apache. :)
Joel Wallis
You might also try
You might also try http://drupal.org/project/modulate to automatically pull them out. (I can't vouch for its efficacy, but it looks like an awesome project.)
probably not very slow
unless people are inputting very slow php code into the fields.
it's worth noting that eval statement's can't be cached by an opcode cache, so if you otherwise rely heavily on an opcode cache, it could be source of slowness. but otherwise i think dalin is correct.
I concur with others. I
I concur with others. I personally hate the PHP filter with a passion and will be glad to see it gone from Drupal 8.
Aside from being slow and insecure, another problem is that this code inherently exists in your database, which is not where code is supposed to be. Want to grep the codebase to try to find a bit of code causing a problem? Code in the database won't turn up in that search. Or what happens if the database gets corrupted, but the codebase is fine? You've got double the headache because some of your code was in the database too. Yay!
Is it worth the effort? I think so. It can be tough, particularly when dealing when Views-related stuff since the learning curve for coding Views-related stuff is less like a slope and more like the cliffs of Normandy on D-Day. But even if it doesn't make your code measurably faster, it will make it immeasurably more correct, secure, and future-proof.
The Boise Drupal Guy!