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.
