On Tue, Mar 2, 2021 at 5:49 AM Yan Titarenko <local.tourist.k...@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/CAOyqgcXrk-4gJ9sMBoj6AunXwO7VSFt%3DzGdRM9A%3D1QxvsujZ3g%40mail.gmail.com.
