3 ms·
Runtime order randomization was added to avoid breaking code that depends on map iteration order; this is necessary to support some of the upcoming planned opti
by shazow 11y ago
Runtime order randomization was added to avoid breaking code that depends on map iteration order; this is necessary to support some of the upcoming planned optimizations.
Committing to supporting any specific sorted order iteration would ultimately come with a performance penalty rather than the reverse.
In fact, this strategy is being introduced to several other aspects of golang's runtime like the test execution order and goroutine scheduler (currently only enabled in -race mode).
- millstone 11y agoThanks for your reply. You and aric both jumped to sorted order as the alternative to randomized order. Why is that? Are you coming from a C++ background?
- shazow 11y agoWhen I say "any specific sorted order" (e.g. whether it's insertion order or ascending value order or whatever) I mean as opposed to unsorted order. That is, not necessarily randomized but necessarily unspecified and not to be relied on. Randomizing is the most explicit example of unsorted order. Go is fairly serious about language stability and they want to hold onto some guarantees for the remainder of Go 1.x. In order to be able to achieve this, they need to be careful about what explicit features they commit to as much as what implicit features people end up depending on. If changing an implemention of a datastructure changes the implicit order of how keys are stored and the entire community has grown to depend on the original undocument order as a feature... then that's a big problem. > Are you coming from a C++ background? I don't think it particularly matters in this case, but the majority of my programming career so far was spent in Python. :)