-
Notifications
You must be signed in to change notification settings - Fork 19
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
better default memory allocation and communication to user #559
Comments
Didn't 1.3 cover some of this? I could be wrong but I thought 1.3 did some memory optimization. |
No, v1.3 did not include anything related to memory use. |
I'd recommend adding #552 to v1.4 also. |
Given the major reduction in memory footprint, is this still a My gut is that we've reduced memory usage enough that this isn't as important anymore -- though I defer to those of you with more experience. |
I've learned to assume a pretty small amount of RAM on computers users might have for RCTab. Assume we have a computer with 4GB RAM - do you have a sense of the vote ceiling there? |
Just ran a basic test -- tabulating 300,000 CVRs out of 1,500,000 records takes 500mb additional memory (in addition to 350mb used just to launch RCTab). That means we'd be able to support 2.4 million CVRs on a 4GB machine - plus/minus a bit, since the rest of the machine will use some memory, but the JVM would also garbage collect more often. However, I have noticed a memory leak -- each time you run a tabulation, more and more memory is used. That could be the cause: if people re-run elections multiple times, each subsequent election has less memory to work with, and it'll eventually hit a ceiling. I think if we solve this leak, we'd solve the overall problem. I'm going to look into that. |
two questions:
|
I'm still working to get a better understanding here. |
|
Alright, I've spent a lot of cycles trying to hunt down the memory leak, and I think I'm chasing a phantom: something somewhere is being cached, and I'm not familiar enough with Java debugging tools to pinpoint what's happening -- but if I wait 15 minutes, the memory decreases, so I think Java is just using the memory available on my machine, and it wouldn't happen in the "real world". If somebody with a Virtual Machine can test this, that would be helpful ( @HEdingfield ?) -- see what happens on a machine with 4gb ram. My gut tells me that we should be fine now, and that we realistically won't be hitting limits anymore, but I'm not 100% confident in that. |
No easy way to test on my end either. I suggest we maybe open up another issue outside of this release to check in on it again in the future (linking back to this one), and maybe close a bit later if nobody else has complained about it. |
Almost a year later -- thinking we can close this @yezr ? |
Looking through all github issues related to memory footprint. I see #640 PR fixing #552 that makes all tabulation use less memory by improving the memory footprint of CVRs. That PR will raise the ballot # ceiling that we can successfully tabulate given the same memory size. I created #824 to revise the ballot to memory estimates we currently have in Section 3 of the TDP. With new ballot to memory estimates we can decide whether this issue is still necessary. Like if a machine with 4GB memory can now reliably do millions of ballots we can drop the priority of this one. |
This is a companion to #552. @moldover's suggestions:
Note: not 100% sure, but I don't think that last idea is possible. The JVM's preference is to make use of the memory you allocate to it, since garbage collection has a non-zero cost. So it will end up consuming most or all of the available heap space during the normal course of operation even when it's actually well within the limits we've defined.
The text was updated successfully, but these errors were encountered: