Generics will solve this.
> On Mar 17, 2021, at 4:23 PM, Matthew Holiday <matthew.holi...@nytimes.com>
> wrote:
>
>
> Isn't this really just another form of issue 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.
>>>>>
>>>>> --
>>>>> 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.
>>>
>>> --
>>> 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.
>>
>> --
>> 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.
>
>
> --
> 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.
--
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/8C8A6F75-FF7E-47A4-BBE5-E939A15A367F%40ix.netcom.com.
