Ajax with php file optimization

Hi guys,

I have a question about optimization.
Okay, so I use ajax on my site.
I put all of my php scripts that are accessed with ajax in one file, like so (you get the outline):

switch ($_GET['script'])
{
case 'script1':
//execute script1 here
break;
case 'script2':
//execute script2 here
break;
case 'script3':
//execute script3 here
break;
default:
//default response here
}

PHP:

Is doing this slower than having scripts one, two, and three in separate files?

Thanks,
-Tony

 

Of course. About .01ms slower. IOW, not in any way that anyone would notice.

Although I'd use isset() on the $_GET['script'] value, in case it's not set. (The user could call your PHP file directly.) I use a large 'if' statement rather than a switch case in my PHP files, but it's about the same thing you're doing.

 

Thanks.
Also, I use isset(), just didn't think it was necessary to show it.

-Tony

 

On this forum you should show everything. If you actually know PHP, and you look at some of the code posted here, you'll hurt yourself laughing. Never assume, here, that the code posted is deliberately leaving something out to save space in the display. I've seen lines with no semicolon, comment begins with no ends (try debugging 300 lines of PHP when the interpreter complains that it reached the end of the file prematurely), missing brackets, braces, parens, etc. I know a few of the people who post here by the coding they've done - I never assume anything about anyone else's coding.

So forgive me if I assumed that you weren't as experienced as your code says you probably are.

 

I'll just take that as a compliment.
I was just saying that I do use isset().

Thanks,
-Tony

 

I would use an include or requires with a variable name that is the same as the name that I would be looking up. Or put the lookup name as a index in mySql to look up the includes name.

That way it is "open ended" and you don't have to keep going back and revising the code.

Learned a long time ago, you can put the smarts in the code or put it in the data. Data is easier with the code execution path determined by the data. You might need some exception handling if the data goes wrong.

Makes a lot easier to maintain if all you have to do is enter a new line of data and create the associated stub.

Using templates are another example of this. The php code simply scans the template and replaces the template variables. php code never changes. template and data change

 

Don't know what you mean. Sorry!
Example, maybe?

Thanks,
-Tony

 

Select the name of the include file from the database, then use it in the include statement.

It's one way to do it, but I wouldn't, since if you change the include file name you're probably doing a pretty large rewrite of the site, and changing the include statements is just part of that. It really depends on how large a site it is. I suppose that if you have 2,000 pages, all using the same menu or CSS file, and you want to change just the menu file name or CSS file name, changing it in the database is faster, but how many times do you have to change the file name? You change what's in the file.

 

In the original post the optimization question was about speed or faster. Anymore, code speed is not really a problem with code execution. The speed problems involve things like network speed and server load.

I guess if you got into an infinite loop it could be a problem with code. Or did a lot of sql statements of select * from table with big tables and no indexes code could be a problem

Optimizing the code to run faster (IMHO) is not that productive. It is better to focus on well written, well commented code, and well documented with provisions for easy maintenance and expansion with such things as as a naming variables with descriptive and appropriate names.

Usually the code execution speed to produce an html page is very small when compared to the time it takes the user to come back to the server.

Code speed is more important in systems like payroll and accounts receivable that run a long time.

There are also considerations like exception handling and graceful recovery with complete and descriptive messages. A dialog window that pops up and says "Something went wrong" is not that helpful. Also things like "Are you sure" and "Do you really want to do that" are valid before irreversible changes.

There is also the whole area of object oriented programming, classes, etc.

 

I've done a benchmark with 3 couple of possibilities and the if statement (with else) is much faster then switch.


All codes have been running for atleast 1000 times having $test = 'three';

switch ($test)
{
case "one": break;
case "two": break;
case "three":break;
default: break;
}

Code (markup):

having 356%

if ($test == 'one')
{
}
if ($test == 'two')
{
}
if ($test == 'three')
{
}

Code (markup):

having 101%

if ($test == 'one')
{
}
elseif ($test == 'two')
{
}
elseif ($test == 'three')
{
}
else
{
}

Code (markup):

having 100% where 100% is the fastest option available!

 

So you're saying that consecutive if statements is the fastest option?
Even when using ajax as I described in my first post?

Thanks,
-Tony

 

Eric, the percentages may be of interest to someone trying to optimize PHP itself, but what are the actual times? If we're talking about the difference between 35.6 ms, 10.1 ms and 10 ms, it doesn't make any difference.

 

Alright, so far what I understand is that it doesn't really matter what I use for this very much at all.
Because the switch statement makes a lot of sense to me, I'm going to keep using it.

Thanks to you all.
-Tony

 

What do you mean with actual times? Those diffrences can be from big importance if the script is executed like 1000 a second!

 

What are the actual times?

Thanks,
-Tony

 

This particular script is executed by submitting a form. Anyone submitting a form 1,000 times a second to my site gets permanently blocked long before he reaches that count.

You gave us percentages. How long, in seconds, did 1,000 runs of each code take? That will tell us how long running through the code 1 time takes. If the difference is half a second, it makes a difference. If the difference is a few milliseconds, the user is never going to be able to tell.

If the site is being hit 1,000 times a second (by 1,000 different users), it's a huge server farm, and it still won't make any difference if it's a difference of a few milliseconds. (If you have a shared site being hit 1,000 times a second, your host will shut you down - you need at least a VPS, if not a large server farm.)