Another thing that changed, is that for a few months now, I’v been doing squash. Its a pretty fun game and I’m really feeling better, healthier then I did back when I didn’t do any sports. (Even though since I started at GeoTax I’ve been less active when you look at the total picture – I go there by train, while I used to go to school on my bike, which is a 45 minute drive.) Its strange how two 45 minute sessions a week (which is my goal) can make you feel like you have way more energy.

Between the internship and squashing, I have way less time then I used to. As a result of that, I’m making much less hours at work these days (not that big an issue, as the internship also pays pretty good), I’ve had to cut back on the TV shows I follow (all good shows got cancelled anyway) and I’m reading far less (as in, from a few chapters a day, to one or two a week). I’m also spending much less time online. I don’t read half the articles I would have read if I had the time, and my activity at Zetaboards Support has dropped to an all time low.

Oh, and I have a girlfriend these days. I try to spend what little free time I have with her.

I have been doing a lot more PHP lately then I have in a long while and that, plus the prospect of a pretty big project I will hopefully start on during the summer, made me think a bit about error reporting. I’m not talking about E_ALL vs E_, err, 0. I’m talking about what to tell the user when either (s)he or the application screws up.

As explaining is easier by example, here’s one: your application has a login section which grants access to who knows what. A user wants to log in, has the correct username but the wrong password. Do you simple tell them “invalid credentials” or is it something along the lines of “Sorry, $prettyusername, but the password you provided does not match the one in our database. You may try again[link to #login]. You can also recover your password[link to password recovery]“?
From where I stand, both have there up- and downsides. Just telling them they didn’t enter valid credentials isn’t anywhere near userfriendly, but if the user is someone who is trying to break into the application I don’t want to tell them anything.

So, what is more important, being friendly to your users or giving people that try to break in as little help as possible?

How I benchmark

First a short elaboration on how I run my benchmarks.
I benchmark things at a verry basic level. Setup some stuff, start a timer, do something xx times (normally 100,000 or 1,000,000, though it may be up or down a zero for verry light or heavy things.), run what I’m comparing it against the same ammoung of times, print out how long both took. Like I said, verry basic. Note to self: Finish that class for automating this, soon..
For those who care: I run stuff on a Intel Pentium 4, 3066 MHz (23 x 133) (Northwood HyperThreading), 2 X Corsair VS1GB400C3, plugged into a MSI MS-6575E motherboard. My OS of use is Windows XP Professional running Apache/2.0.59 & PHP/5.2.0. (That about sums it up, right?)

isset() vs array_key_exists()

Note that there is a difference between the two. isset($array[$index]) returns false even if it is actually set to NULL, whereas array_key_exists() returns true. Thank you Jeremy for pointing this out.For a project I’m working on with Pete, I’m oftenly checking if an index is set in a array. I normally use isset to do this, but sometimes, for no reason, use array_key_exists() instead. When I looked over some code I has written, I noticed this, and decided to see which is better. I used an array containing incremently more letters of the alphabet, untill an element held all. (So 0 => ‘a’, 1 => ‘ab’,…24 => ‘abc…xyz’) I then had both isset() and array_key_exists() check elements 0 trough 26 (of which all but 26 would be set) 1,000,000 times. (So, 27,000,000 calls to both functions.) There are the results:

In total, this benchmark took 16.87498 seconds.
Times where spend like this:
isset() took 1.5900671482 seconds.
array_key_exists() took 15.2848100662 seconds.

This suprised me, as I would have assumed array_key_exists would be faster. I then wondered, would there be a difference if the keys would be alphanumerical, instead of just numerical?
So, first, I made another benchmark. It was exactly the same, except for the array used; it now was array(‘a’ => ‘a’,…’abc..xyz’=>’abc…xyz’); I did still have both functions check if a numerical value was set. While not 100% unexpectable, this didn’t seem to make a big difference. I then had the functions call the alphanumerical indexes (‘a’ => ‘abc..xyz’) and as 27th check, I used ‘zyx..cba’. My results:

In total, this benchmark took 23.82291 seconds.
Times where spend like this:
isset() took 4.5246219635 seconds.
array_key_exists() took 19.2981789112 seconds.

While still not exactly what I expected (a function written to check if a key is set in an array should be faster then a function written to check if a variable is set and that happens to be able to do the same for array indexes, right?) I do find the relative increases interesting. Even though isset() is still much faster, it seems array_key_exists() is has much less problems with strings. (Note: I tested with different lengh loops, and found that the fact that the used time went up about 4 seconds for each is a coincidense.) I won’t write a conclusion, because I suck at writing those don’t want to make my own thoughts seem like facts, but I know I’ll be sticking with isset() from now on. Isset(), faster in executing and writing. Oh, if your interested in seeing what exactly I did, and how it runs on your system (users of other platforms, both hard- as softwarematic, I’d like to see your results.), just for you, I uploaded a package containing the file here.

Thats it

for now, at least. Yea, I suck at writing out more then one thing at a time. I’m going to post follow-up articles lateron. I hope somebody gets something usefull out of this.