On Wed, Oct 25, 2017 at 9:27 AM, <vadim@radovel.ru> wrote:

Excuse me, does this mean that I should use modules instead of objects if its posible. For example: I have a big list of different modules with the same signature containing some values and functions inside - would it give the best performance in OCaml comparing to classes, objects, etc?

If you can solve your problem without relying on objects, then it is better not to use them. There is nothing wrong with them. It just because it is a very powerful mechanism, that sometimes is not easy to control. They give you an extra flexibility so that you can express more complex abstractions, but this comes with a price. Given your particular example, yes, calling a function is faster, than calling a method, as the latter introduces an extra layer of indirection via the virtual method table. Moreover, if a function is know at compile time, it can be inlined, that may provide even further optimization opportunities. It is very hard in general to inline a method, as a compiler needs a proof that this and only this method will be called in runtime. Moreover, if it is the case (i.e., the method can be resolved in runtime), then it is a signal that an object should not be used at all. Basically, objects should be used when you need an open recursion with runtime dispatch. This is a very rare case, in fact.

25.10.2017, 12:45, "Gabriel Scherer" <gabriel.scherer@gmail.com>:
Object-oriented code tends to generate large intermediate representations, too large to be inlined and too complex to be partially evaluated at compile-time. I wouldn't expect this sort of optimization to work.

You might have better luck with first-class modules if you want some sort of tuple subtyping.
(Performance model: with modules, subtyping coercions are compiled as a field-reordering copy,
so the runtime cost is on the coercion rather than the field access.)

> Also as a related question, is there a way to have the lookup semantics of methods without the open recursion part?

We could add row-typed extensible records to the language. Given how little the object-oriented layer is used in practice, I am not sure that this highly work-demanding addition would be a good use of a contributor's time -- and its utility would have to be weighted against the complexity cost of adding yet another kind of product structure.

On Wed, Oct 25, 2017 at 11:31 AM, Christoph Höger <christoph.hoeger@celeraone.com> wrote:
Dear OCaml users,

consider the following microbenchmark:

<snip>
class s (z : string) (y : int) (x : int) =
object method z = z method y = y method x = x
end

type t = { x : int; y : int; z : string}

let foo_s _ =
(new s) "Example" 0 1

let foo_t _ = {x=1; y=0; z="Example"}

let one_s _ = (foo_s ())#x

let one_t _ = (foo_t ()).x

let fac =
let rec fac n =
    let f =
      let rec f n a = if n <= 1 then a else f (n - (one_s ())) (n * a) in f (* change one_t to one_s or vice-versa *)
       in
    f n 1 in
fac
let bench =
let rec bench n a =
    if n <= 0
    then a
    else (let x = a && ((fac 20) == (20 * (fac 19))) in bench (n - 1) x) in
bench
let test = bench 10000000 true
let main _ = test
</snip>

If I run it with ocamlopt 4.05.0+flambda and -O3, the version that uses one_s takes about 7.5s whereas the one with one_t uses 0.35s. I know that object method lookup is more costly than records, of course. This particular case baffles me, though. Why is the class not completely inlined?

Also as a related question, is there a way to have the lookup semantics of methods without the open recursion part? That is, can I have a class that consists of values, not methods? It would love to have open tuples in some cases. For example, I'd like to write a function that takes a tuple of any length, because it only needs the first element.

thanks,

Christoph