Hacker News Reader

Comment by DeathArrow | Hacker News Reader

Anything object oriented is slower than anything procedural. Boxing and unboxing is expensive, running constructors and destructors is expensive, copying objects is expensive, virtual tables are expensive. And stuff isn't aligned greatly in memory, we can expect lots of cache misses and branch mispredictions.

The fastest possible way is to have C strings in an array and run a function over it.

If there are advantages to OOP, speed is not one of them.

Here's a great talk about software speed: https://www.youtube.com/watch?v=pgoetgxecw8

View on HN

> Anything object oriented is slower than anything procedural.

Well, that's not always true; it's better to use a profiler.

In many cases, it's trivial for the compiler to inline objects (e.g., used as predicates for <algorithm> routines), resulting in better performance compared to the equivalent procedural code.

> running constructors and destructors is expensive

If the object is not polymorphic (and sometimes even if it is), the compiler can inline both the constructor and destructor, resulting in exactly the same assembly output as the procedural code.

These criticisms may apply to Java, but are not so clear cut with C++. Boxing/unboxing doesn’t exist, constructors/destructors have only the overhead you’ve put into them (and as bad as iostreams is, C++’s RAII is as glorious), vtables are only built if you’re using inheritance, and std::vector stores objects linearly in memory, yielding terrific cache and prefetch performance (in contrast with Java and its pointer chasing).

If you aren't using OOP features (such as inheritance), you're not really doing OOP, despite using C++.

In the case of C++ I'd put something like: you can use free or costly abstractions, and OOP in general has a preference towards costly ones.

Also vector is a weird point to make, it's been some time I had to deal with Java (luckily) but arrays there are also linear AFAIK. And there are GCs that have a bump allocator for new objects (not sure if Java fits here), so cache would benefit more than in sparse malloc allocations in C/C++.

> Also vector is a weird point to make, it's been some time I had to deal with Java (luckily) but arrays there are also linear AFAIK. And there are GCs that have a bump allocator for new objects (not sure if Java fits here), so cache would benefit more than in sparse malloc allocations in C/C++.

I think the point is that Object[] in Java is a linear block of pointers to objects, whereas vector<Object> in C++ is a linear block of the objects themselves.

Fair enough. But it is needed to point out that there's a catch in that in order to use dynamic dispatch (subclasses, interfaces, ...) you'd still need to use pointers in C++.

Deep down the problem could be rephrased as "there are no structs in Java". In C# for example you could have a vector of structs and enjoy linear memory access.

That's true. It's also important to note that this feature of C++ actually breaks encapsulation - the size of an object, including all of its private fields, private parent classes etc, is part of the public interface of the object in C++. So whenever you add a new private field to an object, you need to recompile all uses of your class, even if your class is used through a DLL.

Yeah I agree. Can the same be said for functional programming (closures, high order functions, etc)? (not procedural)

As they say, closures are the poor man's objects and vis versa.

That said, most usage of closures in practice tend to have very little state manipulation -- a closure with 5 mutable fields is weird, an object with 5 mutable fields is "clean code" approved. Also, closures have only one entry point which makes making complex ones much more difficult (you have to implement a state machine or dispatch or whatever.)

Standard "design patterns" over-the-top OOP translated to FP would be like passing around collection of closures (one per method) that all alter a big shared mutable state. At that point OOP is definitely going to be faster, but the FP code would be so ugly you wouldn't write it like that to start with.

(As with OO) depends heavily on implementation, but my 2 cents is that functional doesn't apply as much constraints to optimization.

If a compiler is sophisticated enough a functional program should perform as well as a procedural one that uses a comparable garbage collector. But of course real compilers have shortcomings.

I recommend taking a read at Haskell's wiki performance article[1] to have an understanding of the shortcomings that are specific to Haskell.

[1] https://wiki.haskell.org/Performance

Reply on news.ycombinator.com