Oh, it takes my program 28.6 seconds to do that one locally in valgrind...

good enough of a test (but bad time)

update: outside valgrind (in cargo test) it takes .5 or 1 second for 20k and 40k lines respectively

what is the mesh of death really like?
I tried putting 40k 20k-long lines in a grid like sample test 7, but it wasn't nearly as slow

I used real boxes in one place instead of leaking them, and put my caches in a struct I passed around as a reference, and it was almost fast without locking! (and more reliable)

Why would you even need locks here? A fork runs for ~3.5s and it does not use paralellization or any such microoptimizations. You need a good algorithm rather than squeezing cycles out of the CPU.

Sooo
I used alot of mutex locks, and locally it works in valgrind, and on musl libc, but not in glibc without valgrind.
I tried using helgrind, but it just complained about hashbrown's lack of locking and worked fine anyway.

Any idea how I could debug this?
Should I try to rework my solution to work without locks at all?

was looking for a shortcircuit and just the other day was reading that LT, EQ & GT are of the Ordered classtype but never would have thought to shortcircuit like this. Well done.

It took me a long time to complete this kata. Finally, "the mesh of death" cleared under 1s. I tried numerous different methods, but it seems there is only one specific way to do this kata, otherwise failure is inevitable. Bottom line is, don't give up, keep on trying. There is some help available from online sources, but at the end of the day, I had to come up with my own solution.

Agda Translation

Agda Translation

😄

Rejected. The description changes have already been made, and the example test changes wasn't really good for showing the problem anyway.

what should we do with this fork?

Yup, that's the intended solution here

I think I have mixed up a few things in my solution