I am curious, is there any performance gain, like using less memory or resources in PHP for:
50 different setting variables saved into array like this
$config['facebook_api_secret'] = 'value here';
Or 50 different setting variables saved into a Constant like this
define('facebook_api_secret', 'value here');
I think this is in the realm of being a micro-optimization. That is, the difference is small enough that it isn't worth using one solution over the other for the sake of performance. If performance were that critical to your app, you wouldn't be using PHP! :-)
Use whatever is more convenient or that makes more sense. I put config data into constants if only because they shouldn't be allowed to change after the config file is loaded, and that's what constants are for.
In my informal tests, I've actually found that accessing/defining constants is a bit slower than normal variables/arrays.
it's not going to make a different anyway; more than likely whatever you do with these will happen in thousandths of a second.
Optimizing your DB (indexing, using EXPLAIN to check your queries) and server set up (using APC) will make more a difference in the long run.
Performance gains for 50 variables using a different coding technique / clever programming tricks is the wrong way to do things in PHP. Always remember: the optimizer is smarter than you are.
You will not receive any kind of performance gain for either of these. The real question is which one is more useful.
For scalar values (Strings, ints, etc) that are defined once, should never change, and need to be accessible all over the place, you should use a constant.
If you have some kind of complex nested configuration, eg:
$config->facebook->apikey = 'secret_key';
$config->facebook->url = 'http://www.facebook.com';
You may want to use an array or a configuration api provided by one of the many frameworks out there (Zend_Config isn't bad)
Related
First, I apologize if this just a coding style issue. I'm wondering about the pros and cons of assign a new variable for each property or function to just to re-assign an existing variable. This is assuming you don't need access to the variable beyond the scope.
Here's what I mean (noting that the names $var0,... are just for simplicity),
Option#1:
$var0= array('hello', 'world');
$var1="hello world";
$var2=//some crazy large database query result
$var3=//some complicated function()
vs.
Option#2:
$var0= array('hello', 'world');
$var0="hello world";
$var0=//some crazy large database query result
$var0=//some complicated function()
Does it depend on the memory size of the existing variable? I.e., is re-assigning memory more computationally expensive that assigning a new variable?
Is this always a scope issue, meaning you should use Option#2 only if you don't need each of the variable values outside the scope shown here?
Does it depend on what each variable value is? Does re-assigning to different data types have different costs associated with it?
Technically speaking, reusing variables would be (insignificantly) faster. It will make zero difference in measurable performance though.
While hardware gets cheaper and hours get more expensive, you should rather look to have maintainable code. This will save yourself headaches and your company hard dollars in the long run.
Only optimize where enough performance gain can be made to offset the
amount of work (money) you are putting into it.
Nowadays of clouds and server clusters, a-bit-less-optimized code will most likely not make for a slower project in the end. It is more probable that your project will run just as fast, but will take a few more cpu cycles, and therefore cost you a little bit more money to your hosting provider. This minor added cost though, will most likely not weigh up to hours of optimizing for performance gain. Unless, ofcourse, you're asking this because you're developing for Amazon. (and even at places like Amazon, with millions and millions of hits per day, reusing variables will not result any noticable performance gain)
To get back to your question; I believe you should only reuse a variable when it will hold updated content of the original state. But in general, that doesn't happen too much.
I think in the following situation, reusing the $content var is the logical choice to make
function getContent()
{
$cacheId = 'someUniqueCacheIdSoItDoesNotTriggerANotice';
$content = someCacheLoadingCall( $cacheId );
if (null === $content) {
$content = someContentGeneratingFunction();
someCacheSavingCall( $cacheId, $content);
}
return $content;
}
Descriptive code
Also, please be kind to your future self to always use descriptive names for your variables. You will thank yourself for it. When you then make the pact with yourself to never reuse variables unless it logically makes sense, you've made another step towards maintainable code.
Imagine, that in 6 months from now, after you've done another big project - or a more small projects - you get a call from an important client that there is a bug in the old project. Holy !##! Gotta fix that right now!
You open up and see functions like this everywhere;
function gC()
{
$cI = 'someUniqueCacheIdSoItDoesNotTriggerANotice';
$c = sclc( $cI );
if (null === $c) {
$c = scg_f();
scsc( $cI, $c);
}
return $c;
}
Much better to use descriptive variable and function names and to get a code editor with good code completion so you're still coding as fast as you want. Right now, I would recommend Aptana Studio or Zend Studio, Zend has a little bit better code completion, but Aptana has proven to be more stable.
PS. I don't know your level of programming, sorry if I babbled on too far. If not relevant for you, I hope to have helped someone else who might read this :)
Personally I would say you should never ever reassign a variable to contain different stuff. This makes it really hard to debug. If you are worried about memory consumption you can always unset() variables.
Also note that you should never ever have variables names $var#. Your variablenames should describe what it holds.
In the end of the day it's all about minimizing the number of WTFs inyour code. And option two is one big WTF.
Does it depend on the memory size of the existing variable? I.e., is re-assigning memory more computationally expensive that assigning a new variable?
It's about limiting the number of WTFs for both you and other people (re)viewing your code.
Is this always a scope issue, meaning you should use Option#2 only if you don't need each of the variable values outside the scope shown here?
Well if it is in a totally other scope it is fine if you use the same name multiple names. As long as it is clear what the variabel contains, e.g.:
// perfectly fine to use the same name again. I would go as far as to say this is prefered.
function doSomethingWithText($articleText)
{
// do something
}
$articleText = 'Some text of some article';
doSomethingWithText($articleText);
Does it depend on what each variable value is? Does re-assigning to different data types have different costs associated with it?
Not a matter of cost, but a matter of maintainability. Which is often way more important.
You should never use option #2. Reusing variables for unrelated blocks of code is a terrible practice. You shouldn't even be in a situation where option #2 is possible. If your function is so long that you're changing context completely and working on some different problem, you should refactor your function into smaller single-purpose functions.
You should never reuse a variable out of some desire to "recycle" them after the old value is no longer used. If a variable is no longer it should naturally fall out of scope if you're architecturing your software correctly. Your decision should have nothing to do with performance or memory-optimization, neither of which are affected by the naming of your variables. Your only consideration when picking variable names should be producing maintainable, stable code.
The fact that you're even asking yourself whether to reuse your variables means you're using names which are too generic. Variable names like var0,var1 etc are terrible. You should be naming your variables according to what they actually contain, and declaring a new variable when you need to store a new value.
I can define constants in file and then include them, or
I can store them in DB and seed them.
From your experience, which one is better/faster/less resource costly for say .. dozens, hundreds, thousands defined?
This is an ever-present question, which differs from person to person, and is a bit of a balancing act. For me, it all depends on how big and static the data-set is presumed to be. In my applications I have about 10 code points where I will refer to constants rather than going through all the overhead to pull data from a database.
Another benefit of using constants, is you can refer to them throughout the codebase which will help reduce defects and improve semantics, for example:
class Ad
{
const ID_AD_TYPE_BANNER = 1;
const ID_AD_TYPE_SKYSCRAPER = 2;
}
// Somewhere in app
if (array_key_exists(Ad::ID_AD_TYPE_BANNER, $array)) {
However there are a few hmmm downsides? I hesitate to call them downsides because they are not difficult to work around. First, if your constants are ints, and your application ever inputs these contants into a table, you will not be able to join to a 'lookup' table and see the lookup values as part of the query results. Instead you will just have to know what an id of 1 means in the query.
Second, be sure to place constants in common sense locations, and try to namespace if you can, that way you can easily find the values if you end up forgetting what they are. If you have a clever IDE, it will do this for you. Also know that if a constant changes, you will have to do a code push vs manipulating database data directly.
I'd say yes to constants, if the list is relatively small (<25) and not prone to change much, however, if your data won't match these constraints, I would suggest popping them into a database.
I would say that the file would be faster, but could be a bigger size, where as the database would be slower, with having to connect and grab the result and return it. Personally I would use a file.
So you have the option to structure an array as you please knowing that a few lines further down in your code you are going to need to check for the existence of a value in that array. The way I see it you have at least two options:
$values_array = array(
'my_val',
'my_val2',
'and_so_on',
);
if(in_array('my_val', $values_array)) {
var_dump('Its there!');
}
Or you could use an associative array and use the keys to contain your value:
$values_array = array(
'my_val' => '',
'my_val2' => '',
'and_so_on' => '',
);
if(isset($values_array['my_val'])) {
var_dump('Its there!');
}
Which method would you pick and why? Would you be solely aiming to reduce process time or also minimise the amount of memory used?
Perhaps you wouldn't use my two puny methods and have another awesome way to solve this simple problem.
This is a theoretical question with no real world application in mind, but there could be thousands of options in the array. It is a speculative question really to see which method is considered better by everyone. Whether it be considered so for readability, speed or memory usage reasons.
Really? Use the variant, that fits better to your and your applications needs. Especially with so less elements, it is far out of scope of measurement.
But there is a real semantic difference between both. The first one defines a list, the second one defines a map. If $array should represent a list, use the first one, if it should represent a map, use the second one (obvious, huh? ;)).
At all: Let never such micro optimization approaches influence your application design.
Code readability and maintainability always trump optimisation.
The developer-time wasted trying to untangle code that is deliberately obtuse just to save a few microseconds generally outweights the value of those saved microseconds.
If you're writing something where execution speed really makes enough of a difference to care about this sort of thing, then PHP (or indeed any interpreted language) is probably the wrong language. And if you are trying to optimise PHP code, there's almost certainly better places to start than this.
Well, I'd tend to the second one, as I have a feeling that this one is more optimal. And I am using it quite often.
However, if it become a bottleneck, I'd measure alternatives.
Anyway, I would never think of these thing while my arrays being relatively small - up to several hundreds items.
And I would try to avoid such searches on heavy arrays at any cost anyway.
Can any body give me a a introduction of how to program efficiently minimizing memory usage in PHP program correctly and generate my program results using minimum memory ?
Based on how I read your question, I think you may be barking up the wrong tree with PHP. It was never designed for a low memory overhead.
If you just want to be as efficient as possible, then look at the other answers. Remember that every single variable costs a fair bit of memory, so use only what you have to, and let the garbage collector work. Make sure that you only declare variables in a local scope so they can get GC'd when the program leaves that scope. Objects will be more expensive than scalar variables. But the biggest common abuse I see are multiple copies of data. If you have a large array, operate directly on it rather than copying it (It may be less CPU efficient, but it should be more memory efficient).
If you are looking to run it in a low memory environment, I'd suggest finding a different language to use. PHP is nice because it manages everything for you (with respect to variables). But that type coersion and flexibility comes at a price (speed and memory usage). Each variable requires a lot of meta-data stored with it. So an 8 byte int (32 bit) would take 8 bytes to store in C, it will likely take more than 64 bytes in PHP (because of all of the "tracking" information associated with it such as type, name, scoping information, etc). That overhead is normally seen as ok since PHP was not designed for large memory loads. So it's a trade-off. More memory used for easier programming. But if you have tight memory constraints, I'd suggest moving to a different language...
It's difficult to give advice with so little information on what you're trying to do and why memory utilization is a problem. In the common scenarios (web servers that serve many requests), memory is not a limiting factory and it's preferable to serve the requests as fast as possible, even if this means sacrificing memory for speed.
However, the following general guidelines apply:
unset your variables as soon as you don't need them. In a program that's well written, this, however, won't have a big impact, as variables going out of scope have the same effect.
In long running scripts, with lot's of variables with circular references, and if using PHP 5.3, trey calling the garbage collector explicitly in certain points.
First of all: Don't try to optimize memory usage by using references. PHP is smart enough not to copy the contents of a variable if you do something like this:
$array = array(1,2,3,4,5,);
$var = $array;
PHP will only copy the contents of the variable when you write to it. Using references all the time because you think they will save you copying the variable content can often fire backwards ;)
But, I think your question is hard to answer, as long as you are more precise.
For example if you are working with files it can be recommendable not always to file_get_contents() the whole file, but use the f(open|...) functions to load only small parts of the file at once or even skip whole chunks.
Or if you are working with strings make use of functions which return a string offset instead of the rest of a string (e.g. strcspn instead of strpbrk) when possible.
I have found out about the great extract function in PHP and I think that it is really handy. However I have learn that most things that are nice in PHP also affects performance, so my question is which affect using the extract can have, seen in a performance perspective?
Is it a no-no to use for big applications to extract variables outta arrays?
Update:
As the commenter below noted and as I am now keenly aware years later - php variables are copy on write. Extracting in the global scope will however keep the variables from being garbage collected. So as I said before, "consider your scope"
Depends on the size of the array and the scope to which your extracting it, say you extract a huge array to the global namespace, I could see that having an effect, as you will have all that data in memory twice - I believe though it may do some fun internal stuff which PHP is known to do to limit that -
but say you did
function bob(){
extract( array( 'a' => 'woo', 'b' =>'fun', 'c' => 'array' ) );
}
its going to have no real lasting effect.
Long story short, just consider what you're doing, why your doing it, and the scope.
extract shouldn't be used on untrusted data. And it isn't usually useful for trusted data (because there are likely a limited number of known array keys).
I don't see why it should be such a big performance hit, as long as you don't extract huge arrays in big loops.
But I've never found a reason to use extract either :)
Working with arrays in most languages is far better because the compiler and/or interpreter can use SIMD instructions with it.
Also you might notice if some part of your code tries to call one function for each value within the array. From a performance point of view it is more efficient to call the function only once with all the values packed. The overhead of calling a function several times will scale up if the array is too long and makes harder to detect possible optimizations
I once had to debug a script which was crashing; it turns out that PHP was running out of memory.
Part of the problem was that extract() was being used in a loop of 25000 elements. It would only get through about 2300 elements before running out of memory. I replaced the extract (associative array of 4 elements) with manually setting the variables, and the loop was able to get through about 5200 records.
So extract() definitely has performance drawbacks.