a typo: "(i.e., the method can be resolved in runtime)" should be read as "(i.e., the method can be resolved at compile time)" On Wed, Oct 25, 2017 at 9:48 AM, Ivan Gotovchits wrote: > > > On Wed, Oct 25, 2017 at 9:27 AM, 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" : >> >> 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: >> >> >> 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 >> >> >> 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 >> >> >> >