-
Notifications
You must be signed in to change notification settings - Fork 189
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
use J as a binary instead of loading the module ( 120 + MBs ) #22
Conversation
use J as a binary instead of loading the module ( 120 + MBs )
I'm cool with this. Will wait and see if anyone complains about response time. |
@dbashford You should also update the |
@davidworkman9 if you get a second, could you give that a shot? I could, but it would be apples v apples given your memory issues. I'd be curious what the improvement would be vs the 10 -> 135 you mentioned in #21. |
Sorry I took so long, I've been without power at my office for the past 2 days. I tried the latest verison of J and memory usage dropped down to around 70 MB. So about half but still pretty high IMO. |
👍 May go back in some day and allow toggling between two options, one for the speed conscious and another for the memory conscious. Thanks for getting back! |
@dbashford this change doesn't play nicely with npm v3 flattening dependencies loaded as a dependency in another project |
Yeah, so instead of J being at
It is at
|
Curious, @tommygnr, in that situation, is there a |
@dbashford to your first question: Yes j is at |
Addresses issue #21. Slower than before (1), but avoids loading over 120 MB into memory.
I looked for a way to "unload" a module, so we could include it only at "extract" time then unload it when finished with it but everything that I was able to find didn't free up the memory.