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.
