Closed recursion-ninja closed 5 years ago
There is no space leak and fie on your for suggesting there might be.
Seriously, though, didn’t I do a pretty decent amount of testing for space leaks and take care of all of them?
On Oct 5, 2018, at 10:58, recursion-ninja notifications@github.com wrote:
The dynamic characters on large alphabets take far to long to compute. This may be because the FFI binding s to the memoized hashmap have been disabled. If this is the case we should look into re-enabling the FFI. If not, we should find the source of the inefficiency on the Haskell side of the codebase.
If the problem appears to be because the FFi was disabled, this is because there was a strong suspicion of a space leak in the hashmap. Fixing this issue may require fixing a space leak in the memoized hashmap across the FFI.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/amnh/PCG/issues/79, or mute the thread https://github.com/notifications/unsubscribe-auth/AM3OssF9BPJwsWwPjytrp5WkP53Rl9uoks5uh3OUgaJpZM4XKZCs.
@ima-hima see #81
This has been resolved via #81
This was closed prematurely. The dynamic characters are still prohibitively expensive to run.
This has been fixed by more intelligently selecting the 3-way comparison function. See cad21188.
The dynamic characters on large alphabets take far to long to compute. This may be because the FFI binding s to the memoized hashmap have been disabled. If this is the case we should look into re-enabling the FFI. If not, we should find the source of the inefficiency on the Haskell side of the codebase.
If the problem appears to be because the FFi was disabled, this is because there was a strong suspicion of a space leak in the hashmap. Fixing this issue may require fixing a space leak in the memoized hashmap across the FFI.