1

I am building an application which does some heavy repetition of functions.

For instance:

$Class = new Class;
for($i; $i < 1000; $i++) {
    $Class->get_something();
}

I have read so many articles on OOP and why it is slow, but I still don't understand where exactly the "slow" part is. People keep using the world "overhead," is that loading the actual class? Once I require a class, is it now the same speed when I call function or a variable?

John Smith
  • 1,750
  • 3
  • 18
  • 31
  • 4
    OOP as such is not "slow". That's rubbish. Programmers create slow programs. Algorithms might be slow. –  May 02 '13 at 17:30
  • 2
    What kind of profiling/benchmarking have you done to narrow down the slow part of your application to something like this? – Mike Samuel May 02 '13 at 17:31
  • @a_horse_with_no_name then why is everyone saying it's slow? It's just scary lol. – John Smith May 02 '13 at 17:31
  • I don't think you'll find it slow in practice. Once you output data across a network (e.g. echo data to the browser) the difference will be negligible anyway. You can always time it, if you like, but I don't think such levels of optimisation are worthwhile. – halfer May 02 '13 at 17:32
  • Apparently not everyone is saying that. I have never heard that statement - and I have done my share of OO programming –  May 02 '13 at 17:32
  • @halfer This is a large querying application, it loads thousands of websites and takes 30-40 minutes to load a page of data. – John Smith May 02 '13 at 17:32
  • 30-40 minutes to load **one** page? Sounds like your application is totally messed up. –  May 02 '13 at 17:33
  • It queries all the news for stocks then analyzes it... It has to open the page of news then read through it. – John Smith May 02 '13 at 17:33
  • ^ Have you worked out what part is the slow bit, as per @Mike's suggestion? That would be a good step; I doubt it's down to your use of objects. – halfer May 02 '13 at 17:33
  • 1
    If you are considered with performance just go native> – Ed Heal May 02 '13 at 17:34
  • 1
    There are contexts where all kinds of indirection (including, but not limited to, method calls) can have a noticeable impact. However, this is not at all relevant, for more reasons that I can enumerate here (two examples: you wouldn't be using PHP, and unless you already optimized the shit out of a million other things you won't even be able to measure any difference). Ignore anyone who just says "OOP is slow" or something along those lines. Sometimes people say very stupid things. –  May 02 '13 at 17:36
  • 1
    I think the unanimous answer here is that OOP is not slow. – John Smith May 02 '13 at 17:37
  • 1
    Wow, this comment thread got personal fast :) I think the best advice when you have performance problems is to benchmark early and often instead of listening to conventional wisdom. Your application usage patterns probably differ from the kind of micro-benchmarks on which conventional wisdom is based. Ideally your test automation should run benchmarks and record results so that you can narrow down performance regressions to specific changes. – Mike Samuel May 02 '13 at 18:01
  • @MikeSamuel Thanks Mike, that's what I'm doing right now lol. I'm going to benchmark everything. – John Smith May 02 '13 at 18:04

4 Answers4

2

You are touching the very old debate between making a one large query to get your data, or looping over many smaller ones to receive them. And the answer lies in specifics of implementations. In some cases it is faster to call that one function over and over, while other times it will just kill your performance. The "overhead" from just calling a function over and over is pretty minimal, it's the "guts" of it that matter.

Tymoteusz Paul
  • 2,732
  • 17
  • 20
  • I still don't get it. Can you explain what "overhead" is, that's where my confusion lies. What is "guts"? – John Smith May 02 '13 at 17:34
  • http://en.wikipedia.org/wiki/Overhead_(computing) And guts is simple the implementation of said function, what's inside it. – Tymoteusz Paul May 02 '13 at 17:36
  • I've read that Puciek, I'm here because I don't understand it. – John Smith May 02 '13 at 17:37
  • Then maybe you should make it clear what you do not understand? – Tymoteusz Paul May 02 '13 at 17:37
  • "any combination of excess or indirect computation time, memory, bandwidth, or other resources that are required to attain a particular goal" is a very general definition. For someone who has never taken a programming class, it makes no sense. – John Smith May 02 '13 at 17:38
  • Well, you are delving into quite complex subject of performance, so you should be familiar with at least basics of programming. Especially since you are asking an abstract question about it, not how to fix performance issues with one application which can only be answered with another abstract. – Tymoteusz Paul May 02 '13 at 17:41
  • "In some cases it is faster to call that one function over and over, while other times it will just kill your performance." C'mon that is just too general of an answer. – John Smith May 02 '13 at 17:43
  • And how precise and not general was your question? – Tymoteusz Paul May 02 '13 at 17:44
  • Where is the slow part in OOP? Getters and setters? "Overhead"? It just doesn't seem right that someone can't pinpoint where exactly the "slow" comes from. – John Smith May 02 '13 at 17:47
  • 2
    Ask the person who claims the "slow" not an actual OO enthusiast? :) On serious note - it comes from all those little pieces combining, its a half o millisecond there, another half there and we are already millisecond behind. – Tymoteusz Paul May 02 '13 at 17:48
  • alright that answers my question, thank you! – John Smith May 02 '13 at 17:51
1

One thing that can be said is that you shouldn't use loads of useless getters in PHP, since it is true that it can slow down your code. Why don't you do a benchmark yourself, eg :

<?php

class test1{
    private $prop = 1;
    public function get_prop(){
        return $this->prop;
    }
}

class test2{
    public $prop = 1;
}

$t1 = microtime(true);
$obj1 = new test1();
for($i=0;$i<=1000000;$i++){
    $a = $obj1->get_prop();
}
echo 'test1, access with get_prop : '.(microtime(true) - $t1).'ms<br/>';

$t1 = microtime(true);
$obj2 = new test2();
for($i=0;$i<=1000000;$i++){
    $a = $obj2->prop;
}
echo 'test2, direct access to prop : '.(microtime(true) - $t1).'ms';

This outputs :

test1, access with get_prop : 1.7691290378571ms

test2, direct access to prop : 0.38315200805664ms

More than 4 times slower!

darma
  • 4,687
  • 1
  • 24
  • 25
1

It's the function call overhead, but it's negligible under normal circumstances. This applies for functions too, not just class methods. The overhead difference between class methods and functions is even more negligible.

It makes sense to avoid moving that code within a function and use inline code if you're going to run it thousands of times. Otherwise, you won't notice any performance impact.

Don't do this unless you really need to, because you'll end up with badly organized code

nice ass
  • 16,471
  • 7
  • 50
  • 89
  • this is what I was looking for thank you. So functions are slow to call if it's 1000's. – John Smith May 02 '13 at 17:53
  • 1
    Even with thousands it's barely noticeable with the current CPUs. You should run a profiler like XDebug, and analyze the generated cachegrind file. There you'll see what parts of the code slow your app down – nice ass May 02 '13 at 18:06
0

Other resource related to this topic. Static method seems much slower.

Performance of static methods vs. functions

Community
  • 1
  • 1
Kei Sawada
  • 136
  • 4