-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High unmanaged memory use for N:Fractional #879
Comments
Any method calls on Fractional[N] also trigger the same memory spike behaviour |
I guess that depending on Can I ask you what you're using |
Thanks for your reply I had written a few interpolation routines that are able to operate either on Rational or on Double - and in different cases in my code (depending on what precision was needed), I'd use either one of those. So that I didn't have to copy/paste the same code, it was convenient to have those methods take N:Fractional instead. If there was another way to write this generic Rational or Double code, I'd take it. For now, I've just copy/pasted out the methods. |
The problem is likely that |
Thanks so much for this suggestion! In 5 minutes testing, some parsing code I have compiles successfully with N:Field:Order. The key piece interpolation of code doesn't compile because toDouble (understandably) doesn't exist but otherwise seems it will compile (I use various maths operators, isZero, comparators - all seem supported). I have other more urgent issues to deal with for now (since I've worked around all this by copy/paste) but hope to give this a try and reprofile some day when I have time. |
scala 2.12.10
spire 0.14.1
JRE - tested both on JRE8 and JRE11
After hours tracking down a memory spike (that was enough to tip over to an OOM at the JVM process level), I distilled the issue to this:
On first call to this function, memory in the JVM (not managed memory) spikes by about 450MB of RAM. Reproducible with code like
Simply set the debugger on that line and when trying to step in, the process memory spikes. I assume the JIT is processing this. Apart from top etc. the memory spike can be captured by
jcmd
while stepping over that line. For some reason, memory gets allocated here:once the line is completed, all that arena memory gets freed.
With my process only generally needing 200MB of heap memory, having to reserve an extra 450MB is sizeable costly overhead. My alternatives are to unwind the neat typeclasses and copy/paste explicit implementations for Rational vs Double.
In fairness, I don't think this is a Spire issue but probably something at the Scala or JVM level but I'm hoping those familiar with Spire internals and the use of all these generics can distil this into why this is happening any maybe raise it upstream.
The text was updated successfully, but these errors were encountered: