03:54 <discocaml> <leostera> without memprof, what can I do to check what allocations are triggering gc?

04:29 <discocaml> <sim642> With perf you can see GC being triggered but usually I've found it to be more of a distraction there. Where the GC happens isn't representative of the allocations which might be problematic. GC can be triggered completely elsewhere that's not related at all. Or why do you want to know?

04:31 <discocaml> <sim642> The allocation triggering GC is kind of the last straw that pushes it over. The allocations that filled up the heap could happen well before and just stayed live

12:42 <discocaml> <leostera> right

12:42 <discocaml> <leostera> i'm currently using Instruments on macOS and i can see the same

12:42 <discocaml> <leostera> i have an idea of what can be causing this since the "stack trace" i get back puts some gc calls under some other calls

12:42 <discocaml> <leostera> but i don't know if this is accidental or related

12:57 <discocaml> <Et7f3 (@me on reply)> octachron: if we build a ocaml with two Marshall module side by side could we use both at the same time (one for loading 4.05 and one for writing 5) or the runtime changed also ?

13:05 <octachron> Marshall is part of the runtime.

13:06 <octachron> At this point, you will want to build independently the marshaller from C with one version as input and another for output.

13:06 <octachron> But, this is sign of a deeper problem: Marshall is *not* an archiving format.

13:07 <companion_cube> it's a "get it done quick'n'dirty" format

13:09 <octachron> And only for local data

14:47 <discocaml> <Et7f3 (@me on reply)> I asked that because yziquel has difficulty to build old ocaml. Of course if he could build an old ocaml he could just write custom code to convert to json or more standard format

17:53 <h0rror> I don't get Sys.time, it can return a higher value for a program that took less time to run

17:53 <companion_cube> maybe the program ran fully without interruption

17:53 <companion_cube> and in the case which took more wallclock time, the process was competing with other processes

17:55 <h0rror> looks like I misunderstood the documentation and I should be using Unix.gettimeofday then! (trying to do some benchmarks)

17:57 <companion_cube> ah yes, or even better, mtime

17:57 <companion_cube> (the opam package for monotonic time)

17:59 <h0rror> didn't know about mtime, that's cool

18:02 <h0rror> thanks companion_cube

18:03 <companion_cube> 🎉