Which is faster?

Anon

Which is faster?
When loading user info into a mysql database, I notice that both of these php scripts have the same end-result.

method #1
$h["address"] = getenv(REMOTE_ADDR);
$h["agent"] = getenv(HTTP_USER_AGENT);
$h["referer"] = getenv(HTTP_REFERER);

-and-

method #2
$h["address"] = $REMOTE_ADDR;
$h["agent"] = $HTTP_USER_AGENT;
$h["referer"] = $HTTP_REFERER;

My question is: Would "method #2" be slightly faster for the server? The first method looks like it uses "functions." Wouldn't the server have to look up what the function means, then do the function? Whereas the second one just pops that data right into the database?

What do you think?

linus

Following your reasoning, you're probably right: the second method is probably very margninally faster. But consider the advantages of the first method:

More compatible (environment variables won't always be available in the global scope).
More secure (using getenv() makes sure you're getting the value of the genuine environment variable).

Also, although I think your way works anyway, this is the proper way to call getenv():

getenv('REMOTE_ADDR');

Notice the quotes.

Anon

Thank you. But, when you say "environment variables won't always be available in the global scope," does that mean if I change webhosts and use a different hosting service? I mean, if $h["address"] = $REMOTE_ADDR; works just fine today, do you mean that tomorrow, depending who is visiting my website, that may not be available even though I have the same webserver? Or, do you mean that if my script is ported to other servers who have different php configurations, it may not work? Thank you.

Anon

$REMOTE_ADDR relies on register_globals, which starting from 4.1.0 (or was it 4.2.0?) it's off.

Diego

Anon

Further to this, PHP is compiled first and then run; depending on details such as .ini settings and optimiser modules, the different coding styles may be compiled into identical forms, and the difference would be moot, with the only speed difference happing at compile time rather than run time.

Generally speaking though, you'd probably have to run the code several thousand times or so before the difference becomes noticeable. So the priority should be more towards security and clarity. Save speed optimisations for the real timesinks and only worry about these if things really start getting busy.