Always true. But hard to believe that a map could be faster. The array will be on the stack.
On Thu, Aug 30, 2018 at 9:31 AM Marvin Renich <m...@renich.org> wrote: > * Michael Jones <michael.jo...@gmail.com> [180830 11:44]: > > The task to "translate a string through a table" is common. It is a > single > > computer instruction (TR) in the IBM 360 and was extended over time with > > related instructions for conversion in and out of UTF-8, testing before > and > > after translation, and expanded character sizes. Tamás Gulácsi's approach > > would be mine too. > > Wow, that brings back memories! The x86 has xlat as well, which can be > used with lodsb and stosb for efficient string translation. The > question is whether the go compiler will produce optimized code using > these instructions. > > I was not disagreeing with Tamás. My point was simply that without > benchmarking, or prior in-depth knowledge of both how the Go compiler > translates these constructs to assembly and the characteristics of the > processor/motherboard/memory bus, it is hard to say which Go algorithm > is the fastest for the OP's data. > > ...Marvin > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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. For more options, visit https://groups.google.com/d/optout.
