Size vs. Speed

R_J

I have toyed around with xdebug and webgrind. As a source, I've just wildly clicked each link of a fresh 2.1b3 installation. It's the first time I've taken a look at webgrind and I was curious if there would be some obvious points which could be tweaked. Well, to no surprise there are not

So I have taken a closer look at what I've seen and I was surprised that nearly 5% of the time of my sample was used for the C() function (in another sample it was only 2.3% but it should only be an example here).

It goes down to that piece of class.configuration.php:

$Value = $this->Data;
for ($i = 0; $i < $KeyCount; ++$i) {
   if (is_array($Value) && array_key_exists($Keys[$i], $Value)) {
      $Value = $Value[$Keys[$i]];
   } else {
      return $DefaultValue;
   }
}

if (is_string($Value))
   $Result = Gdn_Format::Unserialize($Value);
else
   $Result = $Value;

return $Result;

The type of $Value is tested $KeyCount + 1 times and so my first impression was it should better only be tested once so using a gettype() before that would be better, but I've read that gettype() is much slower than is_array/is_string and additionally $Value seems to have at max 3 items. So using gettype() would really be no gain.
But nevertheless there is an if testing for a "static" value inside of a for loop - so the result will always be the same. So that would perform better, but is more code:

$Value = $this->Data;
if (is_array($Value)) {
   for ($i = 0; $i < $KeyCount; ++$i) {
      if (array_key_exists($Keys[$i], $Value)) {
         $Value = $Value[$Keys[$i]];
      } else {
         return $DefaultValue;
      }
   } else {
      return $DefaultValue;
   }
}
...

Well, now that I've written it down I see two things:

1. I know that it most often is called with an array with just one item, so it might be that the overall performance will instead be worse with my above code, because now it is a if ... for ... if when before it was just a for ... if(a&&b) - code tuning can turn out to be a waste of time!
2. the second if clause in this function (if (is_string($Value))) seems to be "dead". In the for loop I test for is_array and it says else return'. So theis_string` can never be TRUE at that line below.

But although it seems that "my solution" is more a brake than a boost, in principle at least my question remains: would you, Vanilla team, extend the source by a few lines even if there is only a very small performance gain? Or do you put the weight on maintanable source code?

By the way: GetValue has in all my samples taken more than 5% of the time. I'd avoid it whenever possible

R_J

@R_J said:

>

2. the second if clause in this function (if (is_string($Value))) seems to be "dead". In the for loop I test for is_array and it says else return'. So theis_string` can never be TRUE at that line below.

No, that was wrong. $Value is changed inside of the for loop and so it could be a string afterwards...

hgtonight

Apart from the fact that you changed the logic (as you realized in your second post), I personally feel that code clarity is more important than performance. If you must write convoluted code for optimization purposes, document it. Anytime you update that code, update the documentation.

Anything else is asking for a world of hurt.

Then again, what do I know? I primarily write code in an environment where it is easy to use "magic" code that is super fast but a bitch to maintain. I don't really know the best things to do in la-la land (read high-level languages).

R_J

Yeah, I feel the same, but to be honest: I haven't really seen code that could be changed to become better (although I really think that knowing about the resource hungryness of some functions as GetValue could help avoiding them) and I'm not sure if I would recognize such of code

Linc

To latch onto that last point: We hate GetValue and wish we'd never done it, for exactly that reason. We're standardizing on arrays to store/pass data moving forward to remove the ambiguity and move away from the need for that function.

Linc

In general, I value readability over miniscule performance gains. Deciphering under-documented code is a frequent part of my work on Vanilla and it drives me nuts how much time I sink on it.

businessdad

@Lincoln said:
To latch onto that last point: We hate GetValue and wish we'd never done it, for exactly that reason.

Actually, it's one of my favourite functions, despite it being heavy. In some scenarios it's so convenient that I implemented it on other platforms.

As for using arrays, they are all good until they become humongous array structures, like the horrendous ones used in Drupal (arrays of arrays of arrays of arrays), as they are unreadable. I rather use objects, whenever feasible, as I find it easier to manage, organise and extend them.

Linc

@businessdad said:
Actually, it's one of my favourite functions, despite it being heavy. In some scenarios it's so convenient that I implemented it on other platforms.

It's very nice yes... the first hundred times it runs on every pageload.

As for using arrays, they are all good until they become humongous array structures, like the horrendous ones used in Drupal (arrays of arrays of arrays of arrays), as they are unreadable.

I didn't mean we'd be changing our overall structure, only that we'd default to using arrays in 99% of cases so there would be far less ambiguity. Right now you have to trace the code back to know which you're going to get, which is just bad.

I rather use objects, whenever feasible, as I find it easier to manage, organise and extend them.

PHP's functions for dealing with array data far outclass the same for objects. That's the primary reason for choosing arrays.

chanh

Check this out!

"so in a conclusion: objects are slower even on PHP 5.2. Don't use objects unless you really need their oop features."

http://stackoverflow.com/questions/2193049/php-objects-vs-arrays

Linc

They're on 5.5 now. Things have changed a lot.

chanh

array vs object from js perspective.

http://nraykov.wordpress.com/2010/02/01/javascript-arrays-vs-objects/

From my perspective, if you need to iterate over your data object is better but if you know your data by the key then array is better and faster because you can get directly to the item without iterate through the array.

businessdad

@chanh said:
From my perspective, if you need to iterate over your data object is better but if you know your data by the key then array is better and faster because you can get directly to the item without iterate through the array.

That's fairly limited comparison. Objects are not just a way like another to carry data around, they go far beyond that. The fact that JavaScript treats objects a bit like dictionaries is a different story, it's one of the quirks/features of the language, but objects and arrays are not equivalent and should be seen as such.

peregrine

off-topic:
everytime I see the title of this thread. I think of this book "BEAR V. SHARK" which was a pretty good read.

http://www.nytimes.com/2001/12/02/books/in-this-corner-weighing-in-at-1500-pounds.html

The spectacle in question pivots on an oddball proposition: ''Given a relatively level playing field -- i.e., water deep enough so that a Shark could maneuver proficiently, but shallow enough so that a Bear could stand and operate with its characteristic dexterity -- who would win in a fight between a Bear and a Shark?''

chanh

@businessdad, agree on array and object are two different things and good for different purposes.