views:

124

answers:

3

My latest idea for do settings across my php project I am building was to store all my settings in a config PHP file, the php file will just return an array like this...

<?php
/**
 * @Filename app-config.php
 * @description Array to return to our config class
 */
return array(
    'db_host' => 'localhost',
    'db_name' => 'socialnetwork',
    'db_user' => 'root',
    'db_password' => '',
    'site_path' => 'C:/webserver/htdocs/project/',
    'site_url' => 'http://localhost/project/',
    'image_path' => 'C:/webserver/htdocs/fproject/images/',
    'image_url' => 'http://localhost/project/images/',
    'site_name' => 'test site',
    'admin_id' => 1,
    'UTC_TIME' => gmdate('U', time()),
    'ip' => $_SERVER['REMOTE_ADDR'],
             'testtttt' => array(
                     'testtttt' => false
                     )
);
?>

Please note the actual config array is MUCH MUCH larger, many more items in it...
Then I would have a Config.class.php file that would load my array file and use the magic method __get($key). I can then autoload my config class file and access any site settings like this...

$config->ip;
$config->db_host;
$config->db_name;
$config->db_user;

So I realize this works great and is very flexible, in my class I can have it read in a PHP file with array like I am doing now, read INI file into array, read XML file into array, read JSON file into array. So it is very flexible for future projects but I am more concerned about performance for this particular project that I am working on now, it will be a social network site like facebook/myspace and I have had one before prior to this project and once I got around 100,000 user's performance became very important. So I am not "micro-optimizing" or "premature optimizing" I am stricly looking to do this the BEST way with performance in mind, it does not need to be flexible as I will only need it on this project.

So with that information, I always read about people trying to eliminate function calls as much as possible saying function calls cause more overhead. SO I am wanting to know from more experienced people what you think about this? I am new to using classes and objects in PHP, so is calling $config->db_user; as costly as calling a function in procedural like this getOption('db_user'); ? I am guessing it is the same as every time I would call a setting it is using the __get() method.

So for best performance should I go about this a different way? Like just loading my config array into a bootstrap file and accessing items when I need them like this...

$config['db_host'];
$config['db_username'];
$config['db_password'];
$config['ip'];

Please give me your thoughts on this without me having to do a bunch of benchmark test

+2  A: 

Firstly, instead of an included file that returns an array I would instead use an .ini file and then use PHP's parse_ini_file() to load the settings.

Secondly, you shouldn't worry about function calls in this case. Why? Because you might have 100,000 users but if all 100,000 execute a script and need some config values then your 100,000 function calls are distributed over 100,000 scripts, which will be completely irrelevant as far as performance goes.

Function calls are only an issue if a single script execution, for example, executes 100,000 of them.

So pick whichever is the most natural implementation. Either an object or an array will work equally well. Actually an object has an advantage in that you can do:

$db = $config->database->hostname;

where $config->database can implicitly load just the database section of the INI file and will create another config object that can return the hostname entry. If you want to segment your config file this way.

cletus
Why would you recommend that besides that some FW are using it, and it is easily distinguished from PHP code that way? Store it as an array suppose to be the fastest way.
Itay Moav
@Itay Moav: INI files should be faster than PHP arrays, although I'm not accounting for the `__get()` overhead in cletus suggestion of course.
Alix Axel
The only reason I was avoiding using an ini file is because I can't set things like user's IP or current UTC timestamp to one of the values. It just seems like any route I go I am basicly taking an array and then wrapping it in a class which just seems like it is adding a lot of overhead maybe? I should of added to my post, some config items might need to be accessed over and over again on a page. Example if I needed to access the ip setting 10 times on a page then that would be 10 function calls for the same value, what do you think would be the best solution for that type of situation?
jasondavis
@Alix Axel - I can't find any thing in the web that supports that, especially (but not only) if I use some kind of byte code cache. Can you point us to a link/benchmark?
Itay Moav
+1  A: 

IMO these are the fastest methods (in order):

  1. $config['db_user']
  2. $config->db_user directly
  3. $config->db_user via __get()
  4. getOption('db_user') via __get()

Also, you've already asked a lot of questions about your config system, not that I mind but I specifically remembered that you asked a question about whether you should use parse_ini_file() or not.

Why are you repeating the basically same questions over and over again?

I think you're taking premature optimization to a whole new level, you should worry about the performance of 100,000 users iff and when you get 50,000 users or so, not now.

Alix Axel
(removed comments that weren't actually adding any value)
Marc Gravell
+3  A: 

From tests I've seen, I believe Alix Axel's response above is correct with respect to the relative speed of the four methods. Using a direct methods is the fastest, and using any sort of magic method usually is slower.

Also, in terms of optimization. The biggest performance hit for any single request in the system you describe will probably be the parsing of the XML/INI/JSON, rather than the accessing of it via whichever syntax you decide to go with. If you want to fix this, store the loaded data in APC once you parse it. This will come with the one caveat that you will want to only store static data in it, and not dynamic things like the UTC date.

sfrench
+1 for pointing out file access and parsing being the real bottleneck here and for suggesting APC
Gordon