05:30 <adrien> I think I've greatly increased the performance of my compression file sorter; I think I've lowered the algorithmic complexity and a test is down to 10 minutes, down from 75 minutes; basically I replaced "cardinal (union set1 set2)" with set1 being a bigarray with a '1' for member, and then I iterate over set2 (roughly-speaking) and check the bigarray

05:52 <discocaml> <darrenldl> @beheddard companion_cube: selective receive interface with timeout : D <https://github.com/darrenldl/distrproc/blob/main/debug/main.ml>

05:53 <discocaml> <darrenldl> (and with guards)

11:55 <discocaml> <Kakadu> Is it possible to integrate bisect_ppx with cram tests? From brief exploration it looks like that cram tests are totally ignored...

16:10 <companion_cube> That looks nice, @darrenldl

16:29 <discocaml> <RegularSpatula> Yeah bisect_ppx works with cram if you instrument your executables as well as any of your libraries

16:30 <discocaml> <Kakadu> I tried, but it looks like it isn't. Could you point to working demo?

16:41 <adrien> hmmm, I've just extracted my most expensive chunk of code to a dedicated function; it is called only once since the hot loop is inside the function

16:42 <adrien> and it seems the code got ~4x slower

16:43 <adrien> I'm a bit surprised: the function itself doesn't need to be inlined and it's not directly the hottest code since it triggers a few millions calls of something else which is what is the most expensive by itself

16:43 <adrien> any idea of what to look for?

16:44 <adrien> (I'm cleaning the code currently, that's why I'm not showing it immediately but I could if noone has ideas)

16:46 <discocaml> <AngelicDevil> Hello. Can somebody tell me where I can find exercises with variants and records? Thanks.

16:50 <discocaml> <RegularSpatula> Sure, just made this one: https://github.com/mooreryan/bisect_ppx_cram_test_example

19:03 <adrien> I had another try with only less code in a separate function and got something as bad (if not worse) so I tried the opposite approach and put some more code in a separate function, and it's fast again...

19:35 <adrien> code is saner now ( https://gitlab.com/adrien-n/compsort ) but this still requires a modified xz (with a single printf line)

21:40 <mclovin> @adrien, I see that you're using `ifprintf`. I went over the code quickly so I'm not sure of often you're calling your `log` function, but even when you don't print anything and call `ifprintf` it's going to be quite costly as `ifprintf` has to consume all its argument. A solution is usually to do something like this instead: https://github.com/OCamlPro/owi/blob/main/src/log.ml#L10-L14 ; before I was using `ifprintf` in my interpreter, and calling

21:40 <mclovin> my log function on every instruction. Switching to the various `debug0`, `debug1` etc. functions led to a 25% improvement.

21:42 <mclovin> Which function is the one you extracted ?

22:05 <Anarchos> i finally managed to run coqide on HaikuOS, tweaking a bit lablgtk3 to use gtksourceview4.8.4 as a gtksourceview3 ----> https://imgur.com/a/XK0uSIN