Isn't this really just another form of issue 3117 <https://github.com/golang/go/issues/3117>?
On Wed, Mar 17, 2021 at 3:19 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com <tapir....@gmail.com> > wrote: > >> For simple scenarios, compiler optimizations might be possible. >> But for some complicate ones, it is hard for compiler to do optimizations. >> For example, the element is modified by an function between the map >> element getter and setter and the behavior of the function is hard to >> determined at compile time, it might modify or not modify the key. >> > > Yes. I would strongly prefer to have these uncommon cases be slower to > complicating the language. > > FWIW, if anything, the signature would have to take a `func(T) T`, not a > `func(*T)` - values in a map are not addressable for a reason. If we would > use a pointer, it would allow the programmer to retain that pointer outside > of the function, which would not be safe. > > But this also implies that any case covered by that function can be > re-written as > > _tmp := k // temporary variable, in case k is modified > v := m[_tmp] > // do the same as the function would > m[_tmp] = v > > which should easily recognizable by the compiler. That means we would only > need to optimize this simple case and anyone concerned about speed could > rewrite their code into this form to get the same result. > > So, I don't actually think doing it as an optimization is harder or less > powerful than adding this function. It should cover the same cases, without > complicating the language. > > > >> >> On Wednesday, March 17, 2021 at 4:51:09 PM UTC-4 >> axel.wa...@googlemail.com wrote: >> >>> 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 <tapi...@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...@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/52f00985-3e0b-4562-80d9-705ae8e5e507n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/52f00985-3e0b-4562-80d9-705ae8e5e507n%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/CAEkBMfEggD%2BnqVJFismVYK%3DqtviFozVft1jdBuT7-VM8cgxXZQ%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEggD%2BnqVJFismVYK%3DqtviFozVft1jdBuT7-VM8cgxXZQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- *Matt Holiday* Senior Gopher, Marketing Technologies 620 Eighth Avenue New York, NY 10018 matthew.holi...@nytimes.com -- 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/CAGSa1CnPs3jnx07P23rzxKfCjDR0Bq580-k3Gxy0Zj1%3Dqo9dng%40mail.gmail.com.