Actual Performance Costs of OOP Objects

[s.t.s]

There are some here problems where multiple inheritance is desirable, and easy unification of object types (the tagless — variant-less — subtyping) is very useful. The complex related properties and relationships among them are naturally representable with objects.

@Chet_Murthy

Your argument that “objects are an afterthought in OCaml, mostly there for a research paper” might be correct. But I’ll note that in the O-O world, the use of subtyping/inheritance (== “O-O”) has decreased pretty monotonically over time: in C++ with the rise of templates and large template libraries like STL and Boost, most programmers rarely need to construct subclass hierarchies, and more and more, O-O is a tool for building those templates.

I’m trying to work out how to implement a similar concept with modules only. However, as @Chet_Murthy notes, the solution seems to converge to the use of some form of code generation (of which templates an instance).

Are there any serious arguments against the extensive use of ppx for these purposes? With records and relationships, a lot of the problem is indeed syntactic in nature, with the semantical part being the interface itself rather — something that is easily checked by a compiler.

@orbitz

I know @bluddy started this discussion about the performance of OOP, but having followed the discussion leading up to this which was about a more expressive I/O layer in Ocaml, and OOP is a possible answer to that, but not necessarily the only solution.

Well, the OO is quite expressive. However, it seems to me that interestingly there apparently may exist an approach to dealing even with inheritance through the module level consructs (like functors). Yes, even with module system, there’s a significant problem space remaining to be solved somehow — and the solution thereby appears to be through some form of code generation or templating.

I suppose, if we could solve the following three problems without objects in a seamless fashion, then there would be an argument that objects are not really needed:

1. A natural representation of many distinct yet related records with overlapping record fields.
2. An implementation of visitors approach to data traversal.
3. A natural representation of interfaces to databases.

@gasche

@bluddy

To me, it seems like a feature that was put into the language in order to publish a research paper, rather than carrying out the obvious move of implementing a high performance OOP system as is available in other compiled languages.

Well I’m waiting for your PR doing just that.

Many aspects of the OCaml implementation reflect the fact that it’s the product of a small team of people – it’s regularly in the zone where it’s getting 80% of the benefits with %20 of the work. It’s not realistic to expect the same language-engineering approach than what you get from, say, Oracle and its full teams of people extracting extra percents of performance from the JVM. (Or Google and v8, etc.). In particular, the more dynamic the programming-language feature, the harder it is (for everyone) to get reliably good performance. I think you have to accept this idea, and in particular there is no need to get vaguely insulting about it.

This is not to say that people shouldn’t work on making OCaml programs faster (I’m also working on this!), including the object-oriented layer if they feel like it. More power to them! But the particular approach to (1) reasoning about performance and (2) programming-language implementation expectations in this thread is just unhealthy.

It is worth noting that F# has objects. I wonder, what is the level of performance of their implementation…

What is their relative memory consumption?

In principle, we could even store records, and instantiate objects referencing one or more records whenever a more sophisticated interface is desired, just as a special case optimization approach. Still, if the object data representation was compact enough… then even that wouldn’t be necessary.