On Tue, Feb 18, 2020 at 10:37 AM Vincent Blanchon <blanchon.vinc...@gmail.com> wrote:
> @Jan, yes definitely. By the way, here are some numbers from a benchmark I > made with 20 constants: > > name time/op > Stringer-4 4.16ns ± 2% > > StringerWithSwitch-4 3.81ns ± 1% > > StringerWithMap-4 28.60ns ± 2% 20 is a small number. In general, measuring things where one iteration is in single digit nanoseconds can be misleading as discussed earlier. The probably most important thing is how a chosen implementation scales. To measure that, I suggest to make the number of the constants in hundreds, if not thousands and having the loop exercise all the paths, so the branch predictor cannot learn a single, happy one. In any case, it's much safer to shift the time/op to at least microseconds, otherwise the overhead of the test per se becomes comparable to the measured thing and it just adds noise at minimum. > @Pierre, the compilation check can also be done if we do not have a slice. In > my example with the switch, I still kept the compilation check. I can't find any compile time check in your code (the one using the switch) that can detect a constant has changed its value since stringer was run. -- 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/CAA40n-WpoLbj9oeAH1nhNv%2BYROSFh1WGFN_5rBC41wnN%2B3aV6w%40mail.gmail.com.
