when this proposal is accepted, I will send a cl to implement it.

Is this necessary with the new maps.Copy and maps.Clone ?

Where does the assertion that it's inefficient come from?

Is this necessary with the new maps.Copy and maps.Clone ?

Where does the assertion that it's inefficient come from?

using copy which implement by me that i will send it later to clone a new map is faster than for range copy like implement in maps.Clone.

here is the benchmark output and benchmark code:

goos: darwin
goarch: arm64
pkg: github.com/cuiweixie/go_compiler/mapcopy
BenchmarkMapCopyGenernal-10           15          68152461 ns/op        40236508 B/op         20 allocs/op
BenchmarkMapCopyNew-10               370           3172743 ns/op        40236386 B/op         20 allocs/op
PASS
ok      github.com/cuiweixie/go_compiler/mapcopy        2.800s

package mapcopy

import "testing"

var m = make(map[int]int)

func init() {
	for i :=0; i<1000000; i++ {
		m[i] = i
	}
}

func OldCopy(m map[int]int)map[int]int{
	nm := make(map[int]int, len(m))
	for k,v := range m {
		nm[k] =v
	}
	return nm
}

var n map[int]int
func BenchmarkMapCopyGenernal(b *testing.B) {
	for i := 0; i < b.N; i++ {
		n = OldCopy(m)
	}
}

func BenchmarkMapCopyNew(b *testing.B) {
	for i := 0; i < b.N; i++ {
		n = copy(m, len(m))
	}
}

Whatever you are doing in your version of copy, we can do in a compiler implementation of maps.Clone if that seems to be desirable.

Change https://go.dev/cl/471400 mentions this issue: maps,runtime: improve maps.Clone

Whatever you are doing in your version of copy, we can do in a compiler implementation of maps.Clone if that seems to be desirable.

@ianlancetaylor please help to check whether the cl is ok.

I proposed this years and years ago on the Go Nuts mailing list, but it seems totally moot now that maps.Clone has been accepted into Go 1.21.

I proposed this years and years ago on the Go Nuts mailing list, but it seems totally moot now that maps.Clone has been accepted into Go 1.21.

this cl reduce the cost of time that clone a one million kv(map[int]int) from 60ms to 3ms.

From the developments of this proposal, i understand you people want to make the map-copy function to have built-in deep-copy support/feature to improve efficiency..

A similar discussion where myself stated the importance of such deep-copy feature happened during the reflect library proposals and a prototype for deep-copy has been generated if i am not wrong.

That prototype's purpose was not restricted to in-built data-types but more of a generic template for user-defined templates as well..

Linking the Proposal discussion here, hoping it serves some importance: reflect.deepcopy()

Is this proposal ok?

@cuiweixie I see that you've changed the title, and now I'm not sure what the proposal is. Can you clarify? Thanks.

@cuiweixie I see that you've changed the title, and now I'm not sure what the proposal is. Can you clarify? Thanks.

change the proposal to improve map.Clone.

Thanks. Improving maps.Clone doesn't have to be a proposal, so taking it out of the proposal process.

ping

@cuiweixie Sorry, what are you pinging? Are you asking whether it is OK for maps.Clone to call into the runtime? I think that that is OK in principle, and that we should use benchmarks to decide whether to actually do it.

@ianlancetaylor: @cuiweixie posted a CL (471400) with benchmarks.

CL has been merged, why not close this issue?

CL has been merged, why not close this issue?

Hi @cuiweixie, it looks like the commit message in the CL might have said Updates #58740.

If you want a CL to close a issue, you usually would write Fixes #58740 instead. (There are a few other variations that are treated similarly, but Fixes is the most common).

There are some more details in the Commit Message section of the Contribution Guide, including:

The special notation Fixes #12345 associates the change with issue 12345 in the Go issue tracker. When this change is eventually applied, the issue tracker will automatically mark the issue as fixed.

If the change is a partial step towards the resolution of the issue, write Updates #12345 instead. This will leave a comment in the issue linking back to the change in Gerrit, but it will not close the issue when the change is applied.

Separately -- this is a great change! 🚀

CL has been merged, why not close this issue?

Hi @cuiweixie, it looks like the commit message in the CL might have said Updates #58740.

If you want a CL to close a issue, you usually would write Fixes #58740 instead. (There are a few other variations that are treated similarly, but Fixes is the most common).

There are some more details in the Commit Message section of the Contribution Guide, including:

The special notation Fixes #12345 associates the change with issue 12345 in the Go issue tracker. When this change is eventually applied, the issue tracker will automatically mark the issue as fixed.

If the change is a partial step towards the resolution of the issue, write Updates #12345 instead. This will leave a comment in the issue linking back to the change in Gerrit, but it will not close the issue when the change is applied.

Separately -- this is a great change! 🚀

got it. thanks!