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.
