homepage Welcome to WebmasterWorld Guest from 54.237.134.62
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

This 35 message thread spans 2 pages: 35 ( [1] 2 > >     
Got a PHP performance tuning tip?
Habtom




msg:1246520
 5:41 am on May 10, 2006 (gmt 0)

PHP performance tunning tips. Please add to the list.

1. Reduce the number of connections to the DB.
2. Use (for and while) loops wisely
3. Anybody?

Hab

 

RedBaron




msg:1246521
 7:29 am on May 10, 2006 (gmt 0)

Dunno if there is any truth to it or not but I heard using 'single quotes' instead of "double quotes" increases performance... Myth or truth?

dmorison




msg:1246522
 8:56 am on May 10, 2006 (gmt 0)

'single quotes' instead of "double quotes" increases performance

That's true, but i'm not sure how significant the difference is. It's because a double quoted string is scanned for variable references (you can put $variable in the middle of a double quoted string), wheras a single quoted string is not and just blatted straight out.

jatar_k




msg:1246523
 2:53 pm on May 10, 2006 (gmt 0)

try this thread for that answer
Benchmarking Text Output [webmasterworld.com]

>> Reduce the number of connections to the DB

not always absolute, sometimes a couple queries is better than a single one with multiple joins

siMKin




msg:1246524
 3:29 pm on May 10, 2006 (gmt 0)

'single quotes' instead of "double quotes" increases performance

That's true, but i'm not sure how significant the difference is.

It's only true if you write sloppy code. If you keep your variable names outside of the quotes (like you should), you will find no significant difference.
So, it's a myth

Anyways, even with sloppy code and the difference that you find, you can hardly talk about 'boosting' the performance. These differences are so minimal they're not really worth the trouble.

well, to contribute something to this topic. a mistake i often see is this:

for ($x=1; $x<count($array); $x++)

the count() will be performed with every loop, thus slowing down the script. So, it's better to store the size of the array in a variable first and use that in the for-loop

Habtom




msg:1246525
 6:28 am on May 11, 2006 (gmt 0)

Anyother which can make a significant performance difference?

Hab

jatar_k




msg:1246526
 3:16 pm on May 11, 2006 (gmt 0)

don't do OO just for the sake of doing OO

don't include every lib on every page, you probably don't need to

don't instantiate huge arrays of data you aren't going to use. If you need to have huge amounts of data around all the time then look into loading it into memory using apache mem hooks

don't make php do things that could be better offloaded to the db or the OS or even to perl or a shell script

Habtom




msg:1246527
 1:29 pm on May 13, 2006 (gmt 0)

//don't do OO just for the sake of doing OO

Is procedural generally considered to be faster?

Habtom

FourDegreez




msg:1246528
 7:32 pm on May 13, 2006 (gmt 0)

Function calls are expensive. If you're calling a function inside a loop, see if you can inline the code instead. Also, instead of i++ use ++i, unless you really need it to be i++. This won't make a big difference though.

eelixduppy




msg:1246529
 7:56 pm on May 13, 2006 (gmt 0)


Also, instead of i++ use ++i, unless you really need it to be i++.

Is there an actual difference in these two? I thought that they both only existed because of possible errors that could occur from the syntax used(ie ($index++ + $test) should be (++$index + $test))

eelix

siMKin




msg:1246530
 8:02 pm on May 13, 2006 (gmt 0)

Yes, there is a difference.

<?php
$i = 1;
echo $i++;
echo $i;
?>

this will output 12

<?php
$i = 1;
echo ++$i;
echo $i;
?>

this will output 22

So, the difference is that in the first case $i will be printed to the screen before being increased, whereas in the second i is increased first

eelixduppy




msg:1246531
 8:08 pm on May 13, 2006 (gmt 0)

Thanks

eelix

Habtom




msg:1246532
 9:27 am on May 14, 2006 (gmt 0)

ha, go procedural when you can is the advice?

siMKin




msg:1246533
 9:41 am on May 14, 2006 (gmt 0)

of course not.
everything can be written in a procedural, but everything can also be written OO style. If procedural would always be 'better', OO wouldn't have a right to exist.

Of course OO has many advantages and you should never loose them out of sight, just for the sake of speed.
Even, though at first glance OO might be a bit slower because of the overhead of objects, it might also allow for much more efficient code, which could make it faster in the long run. Especially in big projects it could be difficult to keep the code efficient if you wrote it completely in a procedural way.

ergophobe




msg:1246534
 9:12 pm on May 14, 2006 (gmt 0)

- Avoid function calls in loop conditions.

The typical example would be

for($i=0; $i<count($my_array); $i++){
}

This should be rewritten as

$total = count($my_array);
for($i=0; $i<$total; $i++) {
}


'single quotes' instead of "double quotes" increases performance

Yep, I've benchmarked it and many other have. You'll notice that more recnet benchmarks show little or no difference. The underlying code that parses quoted strings and handles variable substitution has been rewritten to make it as efficient as possible in all cases and last I heard there is little or no difference between

$my_word = "obfuscate";

echo "good code should not $my_word";
echo "good code should not " . $my_word;
echo 'good code should not '. $my_word;

These should all be equivalent at this point, though I suppose slightly slower than
echo 'good code should not obfuscate';

Anyway, I posted the benchmarking thread that jatar_k referenced and a few others. I have to say that the big lesson I learned from benchmarking a bunch of stuff is that it is just a waste of time to worry about single quotes versus double quotes or $i++ versus ++$i None of these small changes will add up to a hill of beans. More to the point, if one badly written query on a non-optimized database will use up X, changing every quoted string to the most optimal form will use up 0.0001 X. One "bad" (though possibly necessary) query could take a full second to run and not uncommonly 0.1 seconds for a single query. To get even the small variations I found in the thread referenced, I had to run the test cases tens of thousands of times or using huge strings and running thousands of times.

My top PHP performance tuning tips:

- write organized code that you can understand. Use OOP when it helps toward this goal, divide your script into as many or as few files as necessary to achieve this goal

- don't add features just for features (my corollary to jatar_k's "don't use OOP just to use OOP). Look at most bulletin boards and CMS. What kills them is feature creep. Every time you do a query for something like "Who's online" you eat up lots of resources and, frankly, who really cares?

- put xDebug and CacheGrind on your development platform and if a script is taking a long time to run, profile it and see where the bottleneck is and focus on that bottleneck. Most likely, the bottleneck is due to logic not style. It may be necessary logic as some tasks just take time. That said, if a given function uses up only 0.1% of the execution time used to run the script, what is the point of optimizing that function? At best you get a 0.1% boost at a cost of how many hours?

Cheers,
Tom

henry0




msg:1246535
 9:26 pm on May 14, 2006 (gmt 0)

Hello Tom,
Good to see you around
is the air better way above :)

Habtom




msg:1246536
 5:19 am on May 15, 2006 (gmt 0)

Thanks Tom.

hughie




msg:1246537
 7:51 am on May 15, 2006 (gmt 0)

One aspect where i was lazy when starting out was when selecting from the database.

I always used to use "SELECT * FROM.." instead of "SELECT Name, ID FROM.." Even when i was only after a one or two fields.

I'm sure that reduces overheads considerably.

Habtom




msg:1246538
 8:50 am on May 15, 2006 (gmt 0)

//I'm sure that reduces overheads considerably.

I always thought so, and it really does.

Habtom

jatar_k




msg:1246539
 3:20 pm on May 15, 2006 (gmt 0)

well said Tom

also use limits and offsets where appropriate on your queries

why return 1K results if you are only going to show 10? It is even worse when you return 1K results and you are showing #900 - #910 and loop through the whole set to get there ;)

eelixduppy




msg:1246540
 11:40 pm on May 15, 2006 (gmt 0)

Back to OO and Procedural programming for one sec. I found a nice little article [zend.com] about these topics and a comparision between the two.

eelix

Habtom




msg:1246541
 5:19 am on May 16, 2006 (gmt 0)

//We can thank the object oriented programmer for the utility and extendibility of Smarty and FPDF.
//We can thank the procedural programmer for the fast, well-working osCommerce and phpMyAdmin.

Nice article eelix.

Habtom

jatar_k




msg:1246542
 5:19 pm on May 17, 2006 (gmt 0)

this library [webmasterworld.com] thread also comes to mind (for those who may not have read it)

Top 100 Signs That I Am Writing Spaghetti Code in PHP [webmasterworld.com]

eelixduppy




msg:1246543
 3:45 am on May 20, 2006 (gmt 0)

If you have many echos in a loop or in another situation, then writing them to a buffer and then flushing the buffer all at once will produce significant performance differences. An example of this is as follows:

for($i = 0; $i < 1000; $i++)
{
echo $i;
}

This method is much slower than something like this:

ob_start();
for($i = 0; $i <1000; $i++)
{
echo $i;
}
ob_end_flush();

Habtom




msg:1246544
 1:43 pm on May 20, 2006 (gmt 0)

Thanks eelix

I have been very lazy to use those. What is the performance difference they make? Any ideas?

Habtom

hughie




msg:1246545
 2:18 pm on May 20, 2006 (gmt 0)

I just ran that and it didn't make any difference, is it only visible when the script is doing lots of other work as well?

arran




msg:1246546
 3:20 pm on May 20, 2006 (gmt 0)

ob_start("ob_gzhandler");

arran.

hughie




msg:1246547
 4:50 pm on May 20, 2006 (gmt 0)

Just ran that (without the gz_handler) on another machine (400mhz laptop) and WOW!

Here's my results
1.36509799957 without ob_start()

0.248747825623 with ob_start()

Here's the Script

<?php
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}

$time_start = microtime_float();
for($i = 0; $i < 100000; $i++)
{
echo ' ';
}

$time_end = microtime_float();
$time = $time_end - $time_start;

echo $time.' <br /><br />';

$time_start = microtime_float();
ob_start();
for($i = 0; $i <100000; $i++)
{
echo ' ';
}
ob_end_flush();

$time_end = microtime_float();
$time = $time_end - $time_start;

echo $time.' <br /><br />';

?>

superfora




msg:1246548
 4:13 am on May 24, 2006 (gmt 0)

May I use a string as a buffer, catenates all ouput into a string, and echo the string once at the end. Output buffer or string, which is better?

Also, is it necessary to have a redundant ob_end_flush() at the end of a script?

Using php cache is another performance boost, but I still don't know how to use it.

eelixduppy




msg:1246549
 10:56 am on May 24, 2006 (gmt 0)

You can use a string as a buffer, although i don't see why you would since there are buffer functions that pretty much already do this for you. I don't know if using a string instead of php's buffer will cause any performance differences. As for it being necessary to add ob_end_flush at the end of the script...well.....no, its not necessary because it will automatically do it by the end of the script anyway, but I think that its good practice to use it though.

This 35 message thread spans 2 pages: 35 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved