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. 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/5ea4bea1-76f5-4a16-90fd-4ad93fc75539n%40googlegroups.com.
