greg wrote: Abhishek Reddy

Abhishek Reddy — Thu, 16 Apr 2009 18:16:14 +0000

greg wrote:

Abhishek Reddy wrote:

Sounds like you're over-optimising, and prematurely.

You were advising me to future proof mysql in another thread, even where I'd said it wasn't necessary. I would have thought coding PHP to best practice and getting the maximum efficiency is also paramount.
I don't really know the efficiency, which is why I asked.

What I suggested regarding SQL wasn't an optimisation; it was good design. The idea is closer to writing safe and readable code as I suggested here, than it is to squeezing out nanoseconds of speed in a few request cycles.

Of course, one consequence of good design is typically some performance benefit, which I pointed out in the other thread. However, that doesn't mean every technique for improving performance is necessarily due to good design (it rarely is).

Also, speed (time complexity) is only one dimension. You have to consider space complexity, structural complexity, readability, safety, and so on, too.

greg wrote:

One var is in a header included in all pages, and while I know this one particular instance isn't going to cause any great upset to resources, when this is done with many variables throughout the site, I presumed it can add up.

That is a fine presumption for a hypothesis. I encourage you to test it experimentally before worrying about the real cost.

Hmm, interesting

greg — Thu, 16 Apr 2009 15:19:05 +0000

Hmm, interesting comments!

Abhishek Reddy wrote:

Sounds like you're over-optimising, and prematurely.

And I am investigating everything possible in learning to maximise efficiency in all code. I just wondered what sort of impact this may have - especially when multiple instances.

Using @ sounds like a good option in some cases - of course only when the var is known to only return notices, and not errors or warnings. As suppressing error logs is a bad thing of course.

Initializing vars is also another good option, but this adds to the discussion really.
As my particular var in question doesn't get used unless it is something specific, initialising the var to null means means it is actually been set.
Again, one var isn't an issue, but when you need to initialise hundreds of vars throughout the site, it can add up. Especially when a lot of them might not be used, if they are in an if/else, include file etc.

I believe that always

pr0gr4mm3r — Thu, 16 Apr 2009 09:42:45 +0000

I believe that always initializing your variables is a good habit. It's probably a left-over habit from register globals, but there is still the possibility that the same variable was used somewhere else.

Why do you think checking if

Abhishek Reddy — Thu, 16 Apr 2009 09:02:56 +0000

Why do you think checking if a variable is set is inefficient, or will be less efficient than suppressing a warning? Are you checking millions or thousands of variables per cycle, or a dozen, or one?

Sounds like you're over-optimising, and prematurely. I would aim for clarity: explicitly checking if the variable is set documents for readers the fact that the variable is not always expected to be set. Omitting the else-branch documents the fact that its absence is unimportant.

Using @ might also work, but it's a blanket suppression, rather than specifying the single condition you care about.

IMO, it is best to write

Greg K — Thu, 16 Apr 2009 03:41:29 +0000

IMO, it is best to write with no notices. however, you could do the following where you KNOW it is not going to cause a problem:

if (@($variable == "text"))

The @ tells it to suppress any warnings/notices.

-Greg

In a talk given at

teammatt3 — Thu, 16 Apr 2009 02:42:37 +0000

In a talk given at Drupalcon, Rasmus Lerdorf briefly mentions that regardless of how the error reporting level is set, PHP still builds the error string. So you will waste a bit of time doing a bunch of string concats. As long as your error reporting level is set low enough, I don't think PHP pops open the error log.

It doesn't bother me, though.