Golang Performance Optimization

This is a creation in Article, where the information may have evolved or changed. > article is mainly for reference * * Rain SCAR Academy (subscription number) * * and other netizens blog and then according to their own understanding of the collation. # # string and []byte mutual conversion in the process of writing a program often encounter string and []byte conversion, but this conversion is a cost, string and []byte does not share the underlying memory space, so each conversion is accompanied by the allocation of memory and the underlying byte copy. We can improve performance by using unsafe to complete pointer-type conversions, bypassing memory allocation and replication. * * belongs to the Black magic, try not to use. * * "' go/* struct string{uint8 *str; int Len; } struct []uint8{uint8 *array; int Len; int cap; UIntPtr is the built-in type of Golang, is the integer that can store pointers, the underlying type of uintptr is int, and unsafe. Pointer can be converted to each other. But the converted string and []byte shared the underlying space, if modified []byte then the value of the string will also change, it violates the string should be read-only specification, may cause unpredictable effects. */func Str2byte (s string) []byte {x: = (*[2]uintptr) unsafe. Pointer (&s) H: = [3]uintptr{x[0],x[1],x[1]} return * (*[]byte) (unsafe. Pointer (&h))}func byte2str (b []byte) string{return * (*string) (unsafe. Pointer (&b)} "# # Map Usage Notes + * * Preset capacity * * Map can be dynamically expanded, so we can not care about the size of the map, but each dynamic expansion will need to pay the data copy and re-hash cost, if we can know in advance a map of the final capacity , it is best to specify it at initialization time. "' Bigmap: = Make (map[int]int,100000) ' + * * Direct storage of small object values instead of pointers * * For small objects, it is far more efficient to simply leave the data to map and save it with a pointer. This not only reduces heap memory allocations, but the key is that the garbage collector does not scan non-pointer-type Key/value objects. '//Store value object m: = Make (Map[int]int,1000) for I: = 0; i<10000;i++ {m[i]=i;} Store pointer object//If value is a small object, direct storage of values will be better m: = Make (map[int]*int,1000) for I: = 0; i<10000;i++ {value: = i m[i]=&value ;} "+ * * Manually delete Map**map with no elements can dynamically expand, we can constantly add new elements to the map, but the map does not automatically shrink the space, even if all the elements in a map are deleted, the map will still retain all allocated space. ' var dict map[int]int = Make (Map[int]int) for I: = 0; i<100000;i++ {dict[i] = i}for key: = Range Dict {Delete (key)//Even if all elements are deleted, the capacity of dict is still >=100000}//if dict is no longer used then manually set to nil//dict=nil///can also point dict to a newly created small map, The memory space occupied by the original map will be recycled//dict = make (Map[int]int) "# # # Learn Deferdefer is a very useful keyword to improve readability and avoid resources not being released, it is a powerful tool to write reliable, stable programs using Golang. The expression after defer is placed in a stack-like structure, and the expressions in the list are executed in last-in, first-out order when the current method returns * *. Defer itself will have a certain performance loss, but compared with the benefits it is not worth mentioning, we need to note that the key point is that the defer expression will be called when the * * function is returned, meaning that some resources can only be released at the end of the function. ' Func f () {M.lock () defer m.unlock ()//.... Business processing logic//This is a very common locking method, but M.unlock () is only called when the function returns, and if the business processing logic takes a long time, it will always occupy the lock and severely affect performance in high concurrency situations. The solution is to find the * * Minimum critical area * * to release the lock in time after the minimum critical area has been processed. } func F () {M.lock () //... Minimum critical area m.unlock ()//... Continue processing} ' # # # string Splicing string concatenation probably has the following several ways + FMT. Sprintf ("%s%s%d%s%s", "Hello", "World", "Come", "on")//This method is the least efficient, but the code is the simplest and most elegant + uses "+" stitching string "Hello" + "world" + StrConv . Formatint (2016,10) + "Come" + "on"//than FMT. Sprintf () is a bit more efficient, but the code is hard to read + use strings. Join () assembles parameters into []string and then calls Strings.join, the most efficient way to recommend using ' STRs: = []string{' Hello ', ' world ', StrConv. Formatint (2016,10), "Come", "on"}STR = strings. Join (STRs, "") "why use String. Join efficiency is best, look at the strings. Join Code "func join" (A []string, Sep String) string {//calculates the length of the final string, creates []byte] based on the final length, avoids memory reallocation during splicing N: Len (Sep) * (Len (a)- 1) for I: = 0; I < Len (a); i++ {n + = Len (A[i])}b: = Make ([]byte, N)//using the copy function is the most efficient BP: = Copy (b, a[0]) for _, S: = Range a[1:] {bp + = copy (b[bp:], Sep) bp + = copy (B[BP:], s)}return string (b)} ' + but sometimes it's difficult to stitch parameters into []string, when we can use byte. Buffer "var buffer bytes. Buffer for I: = 0; i < 1000; i++ {buffer. WriteString ("A")} ' # # # # # # # # # # # # # # # reflect the performance impact reflection brings great convenience, but also has some performance loss. In modules with high performance requirements, you should pay attention to the performance loss caused by reflection. JSON is aCommon data Interchange Format, but the Encoding/json library of Go relies on reflection to serialize and deserialize JSON. Using [Ffjson] (Https://github.com/pquerna/ffjson), you can avoid the use of reflection by using code generation, which can increase the performance by up to a factor of twice compared to using a native library. # # Channel is not very efficient using golang language programming there is an important idea is ' Don ' t communicate by sharing memory, share memory by communicating. ' And the channel is the communicate between different goroutine. But [the underlying implementation of the channel] (Http://shanks.leanote.com/post/%E6%B7%B1%E5%BA%A6%E5%89%96%E6%9E%90channel) is not unlocked, Reading and writing data into the channel need to be locked, and the strength of the lock is still very large. In some cases, the use of atomic can be used to implement a lock-free structure [(ring buffer)] (https://github.com/Workiva/go-datastructures/blob/master/queue/ring.go ) to replace the channel to improve the performance of the program. In some cases, sync is used. Mutexes and Atmoi are more concise than the more efficient code for using the channel. ' Use whichever are most expressive and more simple ' # #参考文献 * * Rain SCAR Academy * * (subscription number) [Go high performance programming Tips] (http://studygolang.com/articles/6859 Fr=email) [Golang: Using unsafe operation not exported variable] (http://my.oschina.net/goal/blog/193698) [How to efficiently concatenate strings In Go] (http://stackoverflow.com/questions/1760757/how-to-efficiently-concatenate-strings-in-go)