Yes, Jan's link also pretty clearly shows that this optimization isn't currently happening :) Sorry for the noise. I still believe it should be an optimization in the compiler, not a language-level feature.
On Wed, Mar 17, 2021 at 9:44 PM tapi...@gmail.com <tapir....@gmail.com> wrote: > > I found this performance difference by benchmarking the two: > > func IntAdd(words [][]byte) map[string]int { > var m = make(map[string]int) > for _, w := range words { > m[string(w)] = m[string(w)] + 1 > > } > return m > } > > func IntIncrement(words [][]byte) map[string]int { > var m = make(map[string]int) > for _, w := range words { > m[string(w)]++ > } > return m > } > > IntAdd is obviously slower than IntIncrement. > > On Wednesday, March 17, 2021 at 4:22:53 PM UTC-4 axel.wa...@googlemail.com > wrote: > >> Hi, >> >> have you verified this using a disassembler or benchmarks? Just asking >> because this is, as far as I'm concerned, a job for the compiler, to >> eliminate the overhead automatically - and I could well imagine that it's >> already doing it. There definitely shouldn't be a new language construct >> for this. >> >> On Wed, Mar 17, 2021 at 9:19 PM tapi...@gmail.com <tapi...@gmail.com> >> wrote: >> >>> Now, to modify a map element, especially the element type is not a basic >>> type, two hashes are needed to compute. This is often unnecessary and >>> inefficient. For example: >>> >>> package main >>> >>> type T struct{ >>> N int >>> // ... more fields >>> } >>> >>> func main() { >>> var m = map[string]T{} >>> m["foo"] = T{N: 0} >>> >>> // modify >>> t := m["foo"] // first hashing >>> t.N++ >>> m["foo"] = t // second hashing >>> } >>> >>> Will it be good to add a new builtin function, modify(m Map[Key]Value, k >>> Key, func(v *Value)), to modify map elements with only one hash? A use >>> example: >>> >>> package main >>> >>> type T struct{ >>> N int >>> // ... more fields >>> } >>> >>> func main() { >>> var m = map[string]T{} >>> m["foo"] = T{N: 0} >>> >>> // modify >>> modify(m. "foo", func(t *T) { >>> t.N++ >>> }) >>> } >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/ba7b2c95-829b-4da4-916a-d53a06ec3428n%40googlegroups.com >>> <https://groups.google.com/d/msgid/golang-nuts/ba7b2c95-829b-4da4-916a-d53a06ec3428n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d763c1fd-6e57-41f1-90e1-98a369ddf3bcn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d763c1fd-6e57-41f1-90e1-98a369ddf3bcn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE2OdLmhSt91%3DECVgL2ABWemVvzZnPccvnc8B%3DbbiVRbA%40mail.gmail.com.