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

Comments

Projects
None yet
5 participants
@randall77
Copy link
Contributor

commented Oct 26, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 26, 2016

@gopherbot

This comment has been minimized.

Copy link

commented Oct 27, 2016

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

@aclements

This comment has been minimized.

Copy link
Member

commented Oct 27, 2016

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

@randall77

This comment has been minimized.

Copy link
Contributor Author

commented Oct 27, 2016

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

@randall77 randall77 closed this Oct 27, 2016

@aclements

This comment has been minimized.

Copy link
Member

commented Oct 27, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2016

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.
You can’t perform that action at this time.