The compiler doesn’t generate any calls to caml_modify from your code, in other words there are no write barriers. The write barrier occurs only if the right-hand side is a heap value, since you’re using immediates (ints) that can’t contain any reference, there is nothing to check here. The following code will invoke the write barrier:
type box = Box of int
let v : box ref = ref (Box 0)
let outer_c n () =
for i = 0 to n do
let {contents=Box x} = v in
v := Box (x + x);
done
The reason why the inner_b is faster, is because it doesn’t perform any effect that is visible outside. In fact it is more like a no-op, so that compiler should erase this code at all. Instead it compiles it just to a loop that increments the loop counter (and do not update the v reference at all), roughly it corresponds to for (int i = 0; i <= n; i++);, this is the x86-64 assembly generated by 4.05 without flambda:
camlExample__inner_b_1204:
.cfi_startproc
.L102:
movq $1, %rbx
cmpq %rax, %rbx
jg .L100
.L101:
movq %rbx, %rdi
addq $2, %rbx
cmpq %rax, %rdi
jne .L101
.L100:
movq $1, %rax
ret
As you may see there are no allocations, just a cycle, that updates the loop variable (+2 on each cycle, due to the OCaml int representation). Concerning the outer_b function it is also compiled to a very efficient code
camlExample__outer_b_1210:
.L105:
movq $1, %rbx
cmpq %rax, %rbx
jg .L103
.L104:
movq camlExample@GOTPCREL(%rip), %rdi
movq 32(%rdi), %rdi
movq (%rdi), %rsi
leaq -1(%rsi,%rsi), %rsi
movq %rsi, (%rdi)
movq %rbx, %rdi
addq $2, %rbx
cmpq %rax, %rdi
jne .L104
.L103:
movq $1, %rax
ret
It also doesn’t have any allocations nor, of course, any write brarriers, the different is the difference between the code that does nothing and the code that does something.
Concerning the general advice on how to get away from the write barriers. The advice number one (after of course the advice not to use mutable data) would to try to represent your modifiable data as immediate (using interning, for example). You can also try to minimize the number of updates, by gathering the right hand side into one big data structure.
P.S. one of the sources of inefficiency in the outer_b is that you global variable has the external linkage, i.e., it is also shared by other compilation units, providing an empty mli file or wrapping your code in module M : sig end = struct <your-code> end will enable much more efficient code.
Thanks for the advice, let me try to redo the example so I get my original case where the write barrier appeared.