23 June 2010

Config.ini vs. config.php

Прочети статията на български

Recently, I was thinking - what is the best practice to load previously stored settings to your PHP script? One way is to have a PHP file containing define() statements. Then you need to include() the file in your main script and you have access to the options through constants.

Another way is to keep an INI file, and load it by using parse_ini_file() or parse_ini_string() functions. Of course, there are many other possible approaches, but for the most cases using the INI-file or constants methods are the most appropriate ones. So, in short: which is better - the INI file or the constants?

 

Benefits and drawbacks

One thing to consider is if it's about a script that would be used and maintained not only by its creators - a module or even a whole application. It's way more convenient for a user to modify settings in an INI file rather than a PHP one (strictly speaking, having to edit a PHP file is having to modify the source code, which isn't the best way to propose an "interface" to application settings).

Also, using INI files grants you the ability to divide your settings into sections (although this benefit is doubtful, when you can easily just add "SECTIONNAME_" to the identifiers of your constants, and if you really need a tree-style of variables you should consider using XML instead).

On the other hand, parsing INI files using core PHP functions isn't very useful: first of all, you end up with an array of strings (no int or float, not to mention another data types). And, which is of bigger significance, you just can't have any characters you wish in your values, regardless of using INI_SCANNER_NORMAL or INI_SCANNER_RAW in the parse_ini_file/string function. (This particular drawback could be avoided by supplying custom functions to parse INI data.)

And the last, but maybe the most important thing, is the speed. When speaking about a site with heavy traffic, thus frequently loading the settings into the script, the speed is of great importance. I have made the following test:
I generated 100 .ini files containing 100 key-value pairs each. I also generated 100 .php files with 100 constant definitions each. Then I executed 10 times in a row a script that loads all the files and measures the time needed to load them (of course, separate measurement for loading the .ini-s and for the constants). Here are the results on my machine (CPU: Sempron 3100+ @1.8 GHz, RAM: 768 MB DDR400; WAMP):

Seconds to load 10000 values:
Script exec.  INI        Constants
------------  ---------  ---------
1-st time     0.0709*    0.0107*
2-nd          0.0181     0.0031
3-rd          0.0183     0.0023
4-th          0.0183     0.0029
5-th          0.0187     0.0029
6-th          0.0179     0.0021
7-th          0.0182     0.0027
8-th          0.0187     0.0030
9-th          0.0184     0.0022
10-th         0.0188     0.0035

* It's funny to observe how caching of files affects performance
The conclusioin? Using include() to your script and loading configuration values as constants is MUCH faster than loading them from INI file.

 

A short resume

  • Editing configuration stored in INI format is more convenient than editing PHP file.
  • Defining constants by including PHP file into the main script is more safer and flexible in comparison to the INI-load method (unless using custom INI parsing functions).
  • Defining constants is several times faster than loading INI values.

2 comments:

  1. This is an interesting article. I'm most impressed by the benchmarking you've made. However it would be nice to know the parameters of the test machine.
    This article can also serve as a motivation to develop a tool that can combine the good sides of both approaches.

    ReplyDelete
  2. Thanks. I've already added the parameters (though they doesn't really matter for the test purpose). As for that tool you're mentioning about, I have an idea for a small PHP class and maybe I'll post an example in a future post, but I'm not sure yet if it'd be of real value.

    ReplyDelete