I've been doing the AoC problems in kotlin this ye...

# arrow

[bj0]

I've been doing the AoC problems in kotlin this year and today's problem involved caching a recursive search. I tried using MemoizedDeepRecursiveFunction just to test it out but it is running incredibly slow. I suspect something is wrong (maybe a bug?). If i use DeepRecursiveFunction and manually cache it in a Map, the solution runs in ~ 400ms, but if i swap that out with MDRF, and the runtime jumps up to around 20 minutes. Here is my usage: https://github.com/bj0/aoc-kotlin/blob/main/src/year2023/day12.kt#L122

[Youssef Shoaib [MOD]]

MDRF is using an atomic reference under the hood to manage concurrent changes. This results in it copying maps over and over again instead of using a concurrent hashmap or equivalent

[bj0]

That seems counterproductive

[bj0]

is there a proper/different way to use it then? other people said they've used it, but i don't really see why mine would have this issue and others wouldnt'

[bj0]

Ok, it got a lot better when I made the MDRF creation per-call instead of once in a val (like the docs example).

[Youssef Shoaib [MOD]]

That's strange. I'm guessing it's because of the concurrentness. Your function was called in different threads I'm guessing, and hence they were fighting for access to the cache. I think a multi-read, single-write map might be what arrow needs here

[bj0]

i'm not explicitly using any threading, i had assumed it was all running on a single thread, i was guessing the map had just grown too large that the copying was really slow

[Youssef Shoaib [MOD]]

Reported: https://github.com/arrow-kt/arrow/issues/3319

[bj0]

nice, thanks

[Alejandro Serrano.Mena]

our plan is to solve this issue by giving additional configuration options, we even have a PR in review https://github.com/arrow-kt/arrow/pull/3296

[Alejandro Serrano.Mena]

in your case, you could change to use a ConcurrentHashMap instead of an Atomic<Map<...>> and get quite some benefits

[Alejandro Serrano.Mena]

unfortunately, there's no performant-yet-thread-safe Map in the standard library, so we had to recur to that version

[bj0]

Ah that would probably work. Although my case is single threaded so I could just use a stdlib Map