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

runtime: suboptimal size classes #17619

Closed
randall77 opened this issue Oct 26, 2016 · 7 comments
Closed

runtime: suboptimal size classes #17619

randall77 opened this issue Oct 26, 2016 · 7 comments

Comments

@randall77
Copy link
Contributor

It looks like we're allocating objects to size classes suboptimally. Here's an example:

size=4864, pages=2
size=5632, pages=3

the 4864 size class can fit 3 objects in a 2-page span. (Pages are 8192 bytes.)
the 5632 size class can fit 4 objects in a 3-page span.

But consider the size 4864+256=5120. It can also fit 3 objects in a 2-page span. The space usage for that is better than using the 5632 size class. (5461.3 bytes/obj, compared to 6144 bytes/obj).

So the 4864 size class should be 5120. Actually, even 4864+2*256=5376 works.

I'm sure there are more examples, this is just the one I investigated first.

@aclements

@randall77 randall77 added this to the Go1.8Maybe milestone Oct 26, 2016
@randall77
Copy link
Contributor Author

@dvyukov

@gopherbot
Copy link

CL https://golang.org/cl/32219 mentions this issue.

@aclements
Copy link
Member

Huh. Why didn't https://go-review.googlesource.com/24493/ fix this?

@randall77
Copy link
Contributor Author

I am smoking crack. I grabbed the list of size classes before the code from 24493 adjusted them.

@aclements
Copy link
Member

Okay. :) I'm good with statically generating the size classes, though. I've always found it a little odd that we do this at runtime (and annoying, since I can't just look at the size class table), and your static generation CL looks like it has some other nice benefits.

@davecheney
Copy link
Contributor

Please retain the static sizeclass generation, I think that's a useful
change independant of any cocaine freebase.

On Fri, Oct 28, 2016 at 2:22 AM, Austin Clements notifications@github.com
wrote:

Okay. :) I'm good with statically generating the size classes, though.
I've always found it a little odd that we do this at runtime (and annoying,
since I can't just look at the size class table), and your static
generation CL looks like it has some other nice benefits.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17619 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA0RJgx1d3pj3TddbWZNjumYN-npKks5q4MGcgaJpZM4KhoMb
.

@josharian
Copy link
Contributor

Yes, please keep the static sizeclass generation! Very convenient.

@golang golang locked and limited conversation to collaborators Oct 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants