Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
What version of Go are you using (
The runtime wont likely be made depedent on any other package unless its very low dependency and doesnt generate a lot of init work (or needs complex init work). e.g.
The other way around sort and container cant import a runtime function unless it is exported which runtime likely wont for a heap data structure.
This leaves making a new
For http://golang.org/cl/237437 I am not sure the added code is a good fit for the sort package as it will be triggered not very often.
If the improvements on runtime timers can be shown to have a good performance impact on timer benchmarks I would encourage to just send a concrete change list that just changes the runtime implementation for review.
Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For asking questions, see:
Please ask the question on one of the above forums.
(Quoted from https://golang.org/wiki/Questions)
@andybons Thank you for pointing it out. I can submit a PR for the
PR request based on the comment from @Brad Fitzpatrick
@Windsooon one of the Go proverbs is "a little copying is better than a little dependency". This advice applies strongly within the runtime and the standard library because it is easy to create import loops -- we even have tooling inside the bootstrap process to catch new inter package dependencies.
I would advise if you are looking to reduce the number of heap sort implementations in the runtime to consider; are these implementations identical? do they take the same inputs? do the have the same guarantees with regards to stability? do they have the same performance requirements? do they operate allocation free, or can they generate temporary allocations -- this is something which cannot happen inside the runtime.
Is the engineering effort spent to make your change, review it, and then the maintenance of having to use a shared code path in the future justified by the reduction in lines of code, or number of implementations.
I don't wish to discourage you from contributing to the project, but I would suggest that this particular area may not be the best place to start.