CC'ing to Mikko/Justin/taowen/Johannes/Aaron. In case if they would be interested to explain about reflect2's usage.
I tried to patch rook - and here is what I got: https://github.com/advancedwebdeveloper/rook https://gist.github.com/advancedwebdeveloper/52be86fa92fd9ed484ef26f5cbfc541c pkg/apis/ceph.rook.io/v1/cluster.go:40:77: undefined: reflect2.DeepEqual This is not with gollvm: $ go version > go version go1.16 linux/arm64 I could re-check with gollvm. I can tell that I haven't found any build errors, when I patched rook, on behalf of go-reflect. So it could allow to do some benchmarking - we could compare with reflect's performance. On Thu, Mar 4, 2021 at 5:01 AM Sokolov Yura <funny.fal...@gmail.com> wrote: > I use reflect2 in our custom more robust deepcopy implementation in two > places: > > 1. When I need to grow slice. > Standard reflect package has no way to enlarge slice without call to > reflect.MakeSlice, which allocates unneeded slice header. > 2. When I need to iterate map. > Using standard reflect package there is no way to iterate map[string]int > without allocation of string header and int for every key-value pair. When > key or values is struct, things become worse. > Also reflect2.UnsafeMap.UnsafeSetIndex is just a wrapper call to > mapassign. Yes, it is unsafe in the meaning it doesn't check types, but it > is ok in > this place because I've checked types a bit earlier. > > This two things give a lot for performance (and allocation-less-ness) of > our deepcopy. > > Yura > > вторник, 2 марта 2021 г. в 21:18:51 UTC+3, Ian Lance Taylor: > >> On Tue, Mar 2, 2021 at 5:49 AM Yan Titarenko >> <local.tou...@gmail.com> wrote: >> > >> > On Friday, February 26, 2021 at 5:50:44 PM UTC+2 Ian Lance Taylor >> wrote: >> >> >> >> >> >> OK, but the reflect package generally does not allocate, so what is >> >> the advantage of reflect2? Are there benchmarks showing where >> >> reflect2 is significantly faster? >> > >> > >> > The problem is in the fact that benchmarking of json-iterator is itself >> a package specific one. >> > >> > This is not like if we could take 10-15 packages, which use reflect >> package, to benchmark those. And we could each of the end-user Go projects, >> to make it work with reflect2 - and run the same benchmark. Then we could >> patch again, to target go-reflect. Then we could do benchmarking again. >> >> I agree that in general its better to use larger scale benchmarks. >> That said, for a case like this, if reflect2 is faster, it must be >> possible to show that in a micro-benchmark, perhaps one that uses >> b.ReportAllocs. >> >> But really I'm just trying to get at a basic fact. Right now I don't >> understand in what way reflect2 is faster, and the package docs don't >> tell me that either. Do you know? >> >> >> >> >> (I'll note that while this may not be a good idea for the overall >> >> ecosystem, I expect that it is possible to port reflect2 to support >> >> gccgo/GoLLVM.) >> > >> > >> > In that case it would be critical to resolve these issues: >> > https://github.com/modern-go/reflect2/issues/16 >> > . Should those methods and types be referenced? perhaps something else >> should be used? >> > Or it should - but we would have to implement the missing ones? >> > >> > btw this is what never being answered, during all the previous >> discussions. >> >> I'm sorry, I'm not answering the question because it doesn't really >> make sense to me. There is no gccgo/GoLLVM version of a function like >> resolveTypeOff. The fix to make reflect2 work with gccgo/GoLLVM is >> not to add resolveTypeOff to gccgo/GoLLVM. It's to change the >> reflect2 package to work with the gccgo/GoLLVM versions of the reflect >> types. >> >> The gccgo/GoLLVM reflect types are just different from the gc reflect >> types. This doesn't mean that reflect2 can't support gccgo/GoLLVM, >> but it does mean that the package needs to be modified to support >> those types, using appropriate build constraints. >> >> >> > It might make sense to really work on various reflections APIs - to >> learn why it is typically grow into a situation when alternatives are >> written. >> > Perhaps it makes sense to react on various issues and demands, of >> libgo, earlier then the whole Go package (for reflection, in this case) >> would be formed? >> > At least it would be clear that is not reasonable to spend time on >> designing/implementing an alternative, compared to patching libgo's >> package. >> > Also is a "corner edge" case, with json-iterator - it would give some >> disadvantages, in case of other end-user Go package. And that is what >> authors of such "alternative" do not want to deal with - so reflect2 is, >> unsurprisingly, unmaintained even by the original author. >> >> I would certainly be happy to patch libgo if someone can tell me what >> should change. This gets us back to the benchmark discussion. >> >> Ian >> > -- > 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/53f29e5b-385d-4f04-a488-6af1375a91b5n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/53f29e5b-385d-4f04-a488-6af1375a91b5n%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/CANFCsz8%2B44gyHUsPEypLG%2Bqkp8ggz9N_ZSM%2BdCNKpQdvSid7ZQ%40mail.gmail.com.
