Hacker News new | past | comments | ask | show | jobs | submit login

The performance cost is negligible, the randomization happens only at the beginning of a range call:

range init's the hashmap iterator: https://github.com/golang/go/blob/6327e8dc69c47d6355e2623cc4...

hashmap iterator init sets a random starts: https://github.com/golang/go/blob/master/src/runtime/hashmap...




I wasn't referring to the performance cost of randomizing itself, but to the fact that randomization can affect the performance of whatever it is you're measuring.

For example, say you want to benchmark a function that extracts the keys from a map into a slice, and then sorts it via quicksort. Quicksort's performance is affected by the initial ordering, so different runs of the function will behave differently. Was this run really faster, or did I just get lucky with the order this time?


True then, it's not deterministic. I guess that's quite an annoyance actually, you can't use maps in a single threaded program if you want deterministic outcomes? I wonder if the seed of fastrand1 is constant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: