Thank you all for the discussion, it was very helpful! 在2024年12月31日星期二 UTC+8 10:10:12<tapi...@gmail.com> 写道：
> On Tuesday, December 31, 2024 at 9:42:50 AM UTC+8 tapi...@gmail.com wrote: > > On Monday, December 30, 2024 at 6:12:10 AM UTC+8 Axel Wagner wrote: > > Why don't I use the sequence versions more frequently? Because I try not > to create huge in-memory maps and instead prefer to move logic that > manipulates large amounts of data into a proper database. > > > Iterators are more efficient for small maps as well. Allocating and then > throwing away small slices increases GC pressure. I got easily 10% or more > performance improvements by refactoring a loop over a slice with a loop > over an iterator. > > > This is typical micro benchmark. There are too such "allocating and then > throwing away small slices" cases in Go programming. > The iterator cases are just a tiny portion of them. > > > And the iterator cases have alternative no-allocation ways. Many other > cases have not. > > > > > > Then you must REALLY hate that the Go team chose these names in the > standard library: > > # strings Package > - Builder.Write() vs Builder.WriteString() > > - Builder.WriteByte() vs Builder.WriteRune() > - Reader.Read() vs Reader.ReadString() > - Reader.ReadByte() vs Reader.ReadRune() > > > # bytes Package > - Buffer.Write() vs Buffer.WriteString() > - Buffer.WriteByte() vs Buffer.WriteRune() > - Reader.Read() vs Reader.ReadString() > - Reader.ReadByte() vs Reader.ReadRune() > > > All of these exist to implement different interface with different > tradeoffs. For example, `WriteString` implements `io.StringWriter`, which > is more efficient than calling `Write(string(p))`, because the latter would > make the argument escape, thanks to the virtual call. > Yes, it would be better to have simpler names. But given the nature of > interfaces in Go, we need two different methods to do two different things > and they need to have two different names. At least one of them, > unfortunately, has to be bad. > That doesn't disprove the principle, though. > > > > # strconv Package > - strconv.AppendBool() > - strconv.AppendFloat() > - strconv.AppendInt() > - strconv.AppendUint() > - strconv.FormatBool() > - strconv.FormatFloat() > - strconv.FormatInt() > - strconv.FormatUint() > - strconv.ParseBool() > - strconv.ParseFloat() > - strconv.ParseInt() > - strconv.ParseUint() > > > > > # slices Package > - slices.Sort() vs slices.SortFunc() > - slices.IsSorted() vs slices.IsSortedFunc() > - slices.BinarySearch() vs slices.BinarySearchFunc() > - slices.Contains() vs slices.ContainsFunc() > - slices.Index() vs slices.IndexFunc() > - slices.LastIndex() vs slices.LastIndexFunc() > > # maps Package > - maps.Equal() vs maps.EqualFunc() > > > Indeed. If we had more powerful generics (and had them from the beginning) > we could have chosen singular functions with simpler names here. > Perhaps, in the future, we *will* get those and can clean up here. > > > > # bufio Package > - Reader.Read() vs Reader.ReadString() > - Reader.ReadByte() vs Reader.ReadRune() > - Writer.Write() vs Writer.WriteString() > - Writer.WriteByte() vs Writer.WriteRune() > > # archive/tar Package > - Reader.Read() vs Reader.ReadString() > - Writer.Write() vs Writer.WriteString() > > > As above. > > > > -Mike > > > > -- > 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...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/28732884-0E56-4FAA-9DA4-C39700870CC7%40newclarity.net > . > > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/4adbb867-e570-4996-9770-16ade22d00f1n%40googlegroups.com.
