I’d like to understand what the actual performance implications are of OCaml objects. Everyone likes to denigrate them, but what are their performance characteristics really like (and why)?

You should get slightly better performance if you define call as: let call (m : (module A)) y = let module M = (val m) in M.f y or let call y (module M) = M.f y The reason is that (module M) in a function argument prevents un-currying the rest of the arguments, leading to extra closure all…

[image] vlaviron: In fact, you would probably have a fairer comparison if you had written your code as: for i = 0 to 1000000000 do let module M_A : A = M in M_A.f 1 done; The call function introduces overhead that is not present in the other versions. I agree. But unfortunately, OCaml i…

[image] vlaviron: You should get slightly better performance if you define call as: let call (m : (module A)) y = let module M = (val m) in M.f y Indeed, the performances are better. And since OCaml inlines the call to call (but not the one to M.f), this better reflects the actual cost o…

@vlaviron The code is written with let module M = B in ... call (module M); if we wrote call (module B) ... instead, I would have naively expected the (module B) coercion to be recognized as a constant and be allocated statically. But this doesn’t work, and I think it is because the module field rea…

(I haven’t tried to dig into the actual code, so this is mostly (informed) speculation) I believe that recursive modules are unrelated; when you reach Lambda, all field reads are mutable (you might remember that I’ve tried to push for changes to that in the past). The only information that the midd…

That is clearly an unfair comparison :slightly_smiling_face: akin to creating a new object in every iteration of the loop. Normally one would unpack the module outside the loop and call its functions in the loop, which amounts to a record access.

[image] Chet_Murthy: I remember when O-O arrived in OCaml; I even used it for a couple of moderate-sized projects (a big one, a modular packet-sniffer/stream-reassembler/performance-analyzer in 2001), before deciding that it was more trouble than it was worth. And that was when I was well-within…

[image] gasche: n the other side, the Gilian project had a large object-related performance regressions because it uses this kind of objectful AST traversals in performanc-critical paths. (To implement formula substitutions in a symbolic analyser, if I remember correctly.) I wonder if the ob…

[image] nojb: There are some good reasons not to abuse objects: eg their typing theory is more complex than the rest of the core language, but performance is not one of them, in my view. The essential question is whether there exist any principal, theoretical limitations on the possible perfo…

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. [image] Chet_Murthy: Your ar…

Actual Performance Costs of OOP Objects

Learning

s.t.s October 1, 2024, 11:01pm 45

I wonder if the objects are still used in that software?

There has been a rather interesting discussion about object performance on this forum very recently.

Topic		Replies	Views
A Proper OCaml I/O Layer Learning io	14	1716	February 25, 2022
Objects use cases in OCaml Learning oop , objects	38	8956	June 19, 2019
Returning an object with additional fields Learning objects	43	761	October 7, 2024
In defense of OCaml objects Learning objects	4	851	February 29, 2024
Using Ocaml to write network interface drivers Community	24	4905	February 14, 2020

Actual Performance Costs of OOP Objects

Related topics