What is Digg?61 Comments
- phpirate, on 10/12/2007, -0/+14A few of these are completely unnecessary and don't make a difference. Theres a fine line between "optimization" and "good programming practices"
- fffizzz, on 10/12/2007, -3/+11There are some good tips there.... After reading this I actually went and make some changes to my companys internal database app that i designed for them... i got a few slight speed increases.. average page loads on large queries went
from Total Execution: 0.67512607574463 to Total Execution: 0.52172604572414..
not a huge increase but this is an average, sometimes a bit faster. some times not as good.. - bairy, on 10/12/2007, -1/+8Of course. When you're working with code that can execute millions of lines per second you will only ever save microseconds. But they still add up, especially with mysql.
Really big sites with hundreds of mysql queries per minute (e.g. LiveJournal) can really gain from just a little optimisation. Remember that optimising with 1 pageload may save 0.001 secs, that's 0.001 that someone else in the queue is held up for. And then it can start to build up which takes up more cpu and memory in load balancing, which causes people to start clicking refresh adding even more to the load, and suddenly you can have a slow site.
Every optimisation is optimisation. - illynova, on 10/12/2007, -5/+11Actually, most are either common sense or just plain out wrong.
I especially like the one that "...$blah..." is faster than "..." . $blah . "....". Did you ever stop to think *how* the variable got inserted into the string? "...$blah..." is the same thing, except in the second you explicity tell php to concatenate it. - martynda, on 10/12/2007, -2/+8"There are many more useful and easy ways to speed up MySQL."
I'd love to read about them in that case, why don't you show us? - shiftt, on 10/12/2007, -0/+6and if you use something like Turck MMCache to compile and cache your PHP, then it won't matter the slightest bit
- dasil003, on 10/12/2007, -0/+6Here's what you need to know about optimization (I forget what the law is called). If you optimize code that accounts for 1% of your processing time by 100% you still only get 0.5% improvement. And mind you, 100% is a huge improvement to a chunk of code that is reasonably well-written. It doesn't matter how many trillions of hits you get, 0.5% is 0.5%. So before you do any optimization, profile your code and see where you're spending 10%, 20% or 50% of your time. Things like parsing and concatenating strings probably accounts for less than 0.01% of processing time in any application that has a purpose beyond simple text manipulations. So, no, every little bit does not count. At least not in any meaningful way.
- m242, on 10/12/2007, -0/+6No, the LIMIT 1 issue is mostly bs, and won't speed things up at all. As soon as you throw an ORDER BY clause in your statement the database still needs to scan all of the rows.
If you really want to speed up your database queries, you should be using stored procedures, because the database doesn't need to spend unnecessary cycles parsing your query code, etc. Add in a query cache, second-level object cache (a la Hibernate) and page-level caching where possible, and you're good to go. - kerplunk, on 10/12/2007, -0/+5I agree with memcached. I think you would be better offer using APC (http://pecl.php.net/package/APC ) instead of Zend Optimizer, however.
- jkramlich, on 10/12/2007, -0/+5"Only select fields you need, instead of selecting * (everything)."
"Is this right? It still has to scan through the table checking the "WHERE" clause."
Yes, this is correct. When you select more fields than you need, MySQL has to store that unnecessary data in memory. Sometimes, this can be a significant amount of data. This memory can be better used for things such as caches. I would recommend mcache as a PHP interface to memcached. - Ensnared, on 10/12/2007, -0/+4The tip about surrounding strings by single quotes rather than double quotes gets a bit misleading at the final sentence. It's always better to only use single quotes in strings, and use concatenation (sp?) to exit the string and add in variables. It may not speed up a single statement by much, but if it's done all across the board it can lead to quite a noticeable speedup - depending on the application, obviously.
And trust me, it's better to do this from the start than to go through your code and change it when you realise it's a good idea. That can take a very, very, very long time ;)
But overall, very good tips - they may be common sense to semi-experienced PHP-developers, but for someone starting out, it's nice to know these things early on. I sure wish I'd learned these things sooner than I did ;) Digg. - CreepingDeath, on 10/12/2007, -0/+4I agree, some of this is just common sense... nothing bad in there though, and you will save execution time with it, even if we are talking tenths, or hundredths of a second... however if you want to see some real gains, try:
http://www.danga.com/memcached/
and
http://www.zend.com/products/zend_optimizer - proton, on 10/12/2007, -0/+4Re: concat vs interpolation:
http://www.sitepoint.com/blogs/2005/03/07/php-speed-optimizations/ - usefulidiot, on 10/12/2007, -2/+5This is for squeezing the most out of your applications, which can make a large difference on a large scale, as long as the scripts were written with proper design decisions in the first place, good article none the less. If you can optimize, why not?
- dwight0, on 10/12/2007, -0/+3"If you only want one line as a result from the database you should always use LIMIT 1. This way mysql stops searching when it finds the first line instead of continuing through the whole database."
Is mysql smart enough to stop searching if we are find a match for a select on a primary key column (which we usually do)? - proton, on 10/12/2007, -0/+3I've read tests that indicate concatenation is faster than interpolation ('blah ' . $foo . ' blah' is faster than "blah $foo blah"). Will have to find a link...
- Sheco, on 10/12/2007, -0/+3Indeed, It would be kind of dumb to keep on searching once you found a UNIQUE value.
I don't know if mysql does it or not, though. - dasil003, on 10/12/2007, -0/+3You want a real PHP optimization tip? Key large arrays by the values you wish to search the field by and use isset($array[$value]) instead of in_array($value,$array). I can't tell you how much PHP code I've seen where the authors apparently have no idea that associative arrays are indexed and hence much faster than searching values.
- merreborn, on 10/12/2007, -1/+4"MySQL is interpreted from right to left so you should put the most significant limiters as far to the right as possible."
What the hell? Is he advocating putting everything in the HAVING clause, or does he just not know right from left?
The HAVING clause is "right-most", and it's also _completely_ unoptimized! No keys are used, or anything. - Ensnared, on 10/12/2007, -1/+4Nah, smart people just know the difference between "speeding up" and "replacing". You're just not one of them, but I'm sure you've got a large group of peers as well so you shouldn't feel too bad :)
- smhill, on 10/12/2007, -0/+3"Yes, this is correct. When you select more fields than you need, MySQL has to store that unnecessary data in memory. "
Very true, but also if you are concerned about returning extra data that you aren't using very often, optimization can be considered and the schema level instead of the query level.
Often times people get overly concerned about the * select because they have very few tables an poor normalization.
I am not suggesting creating an ass load of tables for everything and joining like mad, but looking at the picture over all. If you have articles for example, and you are hitting that table all the time for titles for lists and such, but not showing the full article all the time, it might be wise to move the body of the article to a separate table. (there are better examples) - pornel, on 10/12/2007, -0/+3Most of these are either wishful thinking or give speed improvement that is too small to reliably measure.
* LIMIT rarely limits processing time - if you have unique indexes, DB will figure it out anyway. If you have more matching results, you probably don't want semi-random one, so you'll have to use ORDER BY, which makes LIMIT useless.
* MySQL has query optimizer, so order of conditions shouldn't matter (order of joins might in complex cases)
* All these variations of PHP syntax have very little effect - PHP file is parsed once and then executed from intermediate code. - bairy, on 10/12/2007, -0/+2vBulletin wasn't /really/ built for speed.
It is optimised quite a lot with it's sql indexing and functions and stuff. But it's really built to be compatible with a huge range of environments, for allowing easy reference to functions, and for allowing one bit of code to be changed instead of 20 bits should a php function need updating (e.g. if php5 makes it better (plus you have to add an if statement to see if it is php5)) which is why you often have "redundant" code and variables all over the place.
It isn't mega-fast but it is compatible and fairly easy to write hacks for. - merreborn, on 10/12/2007, -0/+2"Most of these are either wishful thinking or give speed improvement that is too small to reliably measure."
Indeed. While some of these may save you a few nanoseconds here and there, there's a good chance that an unnecessary nested loop, or unindexed query is taking thousands of times longer than it should.
Find the _real_ trouble spots in your application, and fix _them_. Which style of quotes you use isn't going to make a noticable difference in ANY application. Period.
(Also, the article mentions using , (comma) as a concatenation operator instead of . (period) -- that's pure *****. Period is the only available concatination operator in PHP -- as mentioned on the comments on the site itself.) - bairy, on 10/12/2007, -0/+2Yes
- CreepingDeath, on 10/12/2007, -0/+2Thanks, kerplunk, I'll have to test that out and see how it compares. I started using Zen's optimizer when they released a free version and it did the trick for me, so I just didn't dig much deeper; )
- GrendelT, on 10/12/2007, -0/+2Not to seem bias... but isn't the "digg-effect" like a site getting "farked"... they're both synonyms for the primitive "Slashdot-effect"... am I right?
- EdHaber, on 10/12/2007, -0/+2I can't even find that in the docs. I'm going to have to test it out.
http://www.php.net/manual/en/language.operators.string.php
There they only say '.' and '.=' are for concatenation.
-Ed - bairy, on 10/12/2007, -0/+2You can unsign (make positive only) INTs
- el_taco, on 10/12/2007, -0/+2You would think it's common sense to semi-experienced PHP programmers.. just need to find someone to go through all those tutorials and update them.
- sideral, on 10/12/2007, -0/+1Although I agree with you in every point, echo does "concatenate" using a comma operator. It is like a hidden function that takes a variable number of arguments without parenthesis.
- probablycorey, on 10/12/2007, -1/+2I noticed one problem, he says...
"Use datatypes that fits your data, not too large. For example, INT can hold values up to 4294967295 unsigned, which is often unnecessarily big. Use MEDIUMINT or SMALLINT where applicable. "
But INT's are signed... So they can only hold up to 2147483647 - sideral, on 10/12/2007, -0/+1Two little tips more, worth adding to the list:
1. use preg_* instead of reg_* functions. They're always faster.
2. use ctype_digit, ctype_alpha, etc.. instead of is_int, is_numeric.. ctype_* functions are twice as fast. - inactive, on 11/04/2008, -0/+1calumi, that would be an optimisation in the return data. Returning less data into an array that is essential, is an optimisation over returning everything that includes non-essential data.
- sideral, on 10/12/2007, -0/+1Actually, echo is very special in this behavior. You can put
echo "hello"," world";
and the output will be exactly what is expected from an string concatenation (try it). echo is like a function that takes a variable number of arguments, but without parenthesis - inkswamp, on 10/12/2007, -0/+1Interesting list. I am knee-deep in a fairly massive project involving PHP and MySQL and this was interesting food for thought. I do agree with many of the comments here that some of these seem like they would save a negligible amount of time, if any at all. For example, the concatenation thing seems flimsy. Even if you're putting your variables inline, somewhere along the way, those values have to be interpolated. Whether you're doing it explicitly with an operator or implicitly, the system still has to swap out the variable for the value at some point.
- Deputaats, on 10/12/2007, -0/+1He's saying: "Use NULL as default value as much as you can, it speeds up execution and saves one bit."
In MySQL doc: "Declare columns to be NOT NULL if possible. It makes everything faster and you save one bit per column. If you really need NULL in your application, you should definitely use it. Just avoid having it on all columns by default." --> http://dev.mysql.com/doc/refman/5.0/en/data-size.html - drbaggy, on 10/12/2007, -1/+2A 0.5% increase can lead to a significant server response - especially if you understand gamma processes and load averages. If your box is currently running at 99.9% then then the extra 0.5% means your box is running at 100.1% ie more than it can do - and so all the .1% add up and mean all requests end up delayed!!!
- drbaggy, on 10/12/2007, -0/+0This may speed up individual requests - but having a large number of tables can cause slow downs on a busy server as the system has a limited number of file handles that can link to tables, and you can end up with a large opens/open ratio.
The trick with table partitioning like this is to try and remove non-fixed length fields from tables containing mainly fixed length fields... - thbt, on 10/12/2007, -1/+1Actually, that's what he said:
"Use NOT NULL as default value as much as you can, it speeds up execution and saves one bit." - tybris, on 10/12/2007, -0/+0Now consider all those points, think of how much time they'll take and spend all that time on security because this sure won't make a signficant difference when you're being dugg. If you want to survive massive amounts of visitors do something radical like putting things in ramdisk.
- kevmaster, on 10/10/2007, -0/+0How I managed to easily survive 2 frontpage diggs at the same time. An in depth article.
http://digg.com/linux_unix/How_to_easily_survive_the_Digg_effect - CaseyUCF, on 10/12/2007, -1/+1Yes this is right. It doesn't matter what you specifiy for your WHERE clause you should only select what fields you need.
- Deputaats, on 10/12/2007, -0/+0NULL != NOT NULL
He: column int(10) default NULL
MySQL doc: column int(10) NOT NULL default 0
Or I misunderstood? - dasil003, on 10/12/2007, -1/+1Here's what you need to know about optimization (I forget what the law is called). If you optimize code that accounts for 1% of your processing time by 100% you still only get 0.5% improvement. And mind you, 100% is a huge improvement to a chunk of code that is reasonably well-written. It doesn't matter how many trillions of hits you get, 0.5% is 0.5%. So before you do any optimization, profile your code and see where you're spending 10%, 20% or 50% of your time. Things like parsing and concatenating strings probably accounts for less than 0.01% of processing time in any application that has a purpose beyond simple text manipulations. So, no, every little bit does not count. At least not in any meaningful way.
- bugninja, on 10/12/2007, -3/+2Perfect, now I just need a couple years to go back through my hundreds of thousands of lines of PHP to find all these things. Is there a list of ways to travel through time or how to add extra hours onto a typical day. I'll bet if I stop digging, I get about 30 minutes back every day.
- blueigloo, on 10/12/2007, -2/+1Hmm, been doing PHP for 4 years and didnt know I could concat strings with ',' instead of '.' .....
- bradsh, on 10/12/2007, -6/+4Which is useful when your site is getting hit thousands of times per second. Good, optimized coding really adds up in terms of server load when you start getting lots of hits.
-
Show 51 - 61 of 61 discussions
Check out the new & improved 
© Digg Inc. 2009
— Content created and posted by Digg users is