Skip to content
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

GC is slow. (repair_reference) #12

Open
diiq opened this issue Jun 10, 2010 · 2 comments
Open

GC is slow. (repair_reference) #12

diiq opened this issue Jun 10, 2010 · 2 comments
Labels

Comments

@diiq
Copy link
Owner

diiq commented Jun 10, 2010

Calls to repair_reference make up more than 1/5 of total load time for eight at the moment. GC in general can probably be sped up, but repair_reference is apparently a major offender.

@diiq
Copy link
Owner Author

diiq commented Jul 9, 2010

I've fudged this; GC still takes up almost 1/2 of the total time spent by eight, but it now happens a little less frequently; load-time is significantly reduced. (Which is to say, it will use more memory now than it did before, because it won't collect until more than 10mb are used AND the amount used is more than twice the amount of memory left after the last collection.)

Are there more effective methods for deciding when to garbage collect?

@diiq
Copy link
Owner Author

diiq commented Jul 10, 2010

Aaaand GC is back over 50% of my profiling run:
% cumulative self self total
time seconds seconds calls s/call s/call name
30.18 6.53 6.53 6401 0.00 0.00 collectify
29.05 12.82 6.29 773679948 0.00 0.00 repair_reference
8.23 14.60 1.78 5729077 0.00 0.00 rectify_closing_i
6.38 15.98 1.38 222093785 0.00 0.00 allocatery
4.41 16.93 0.96 67468405 0.00 0.00 cheap_cons

Memory management is taking up 66% of my time. That's not cool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant