thinkeridea / go-extend Goto Github PK

View Code? Open in Web Editor NEW

1.3K 38.0 160.0 189 KB

go语言扩展包，收集一些常用的操作函数，辅助更快的完成开发工作，并减少重复代码

Home Page: https://pkg.go.dev/github.com/thinkeridea/go-extend

License: MIT License

Go 100.00%

go pool bytes net errno round substr

go-extend's Introduction

go-extend

go-extend 收集一些常用的操作函数，辅助更快的完成开发工作，并减少重复代码。

它收集各种杂项函数，并进行归类，方便使用者查找，它可以大幅度提升开发效率和程序运行性能。它以保证性能为最大前提，提供有效的方法。针对一些标准库中的函数或者库进行一些修改，使其性能大幅度提升，但它并不用来替换标准库函数，这些函数往往会在一些场景下有效，但有些函数可以用来替换标准库函数，它们保持一致的功能，且相当安全。

一些包或者函数使用示例及分析可以在我的博客(https://blog.thinkeridea.com) 中找到。

安装

$ go get  github.com/thinkeridea/go-extend/...

规范:

与标准库包名一致的使用 ex 前缀，避免与标准库包冲突
包目录下 doc.go 作为包说明文档

性能测试

包中一些函数会进行性能测试，包括每次修订的性能对比，它们一般位于各自包下面的 benchmark 目录下，性能测试结果可以在 benchmark.md 快速浏览。

标准库函数改进列表

用来替换标准库的函数，它们和标准库函数功能保持一致，并拥有更好的性能：

exstrings.Join 该方法是对标准库 strings.Join 修改，配合 unsafe 包能有效减少内存分配
exstrings.Repeat 该方法是对标准库 strings.Repeat 修改，对于创建大字符串能有效减少内存分配
exstrings.Replace 替换字符串该方法是对标准库 strings.Replace 修改，配合 unsafe 包能有效减少内存分配

用该改善标准库的函数，它们基本和标准库功能一致，但是它们都拥有更好的性能：

exbytes.Replace 它使用原地替换，直接修改输入的数据，获得更好的性能
exstrings.JoinToBytes 它响应一个 []byte 类型，有效避免类型转换
exstrings.RepeatToBytes 它响应一个 []byte 类型，有效避免类型转换
exstrings.ReplaceToBytes 它响应一个 []byte 类型，有效避免类型转换
exstrings.UnsafeReplaceToBytes 它响应一个 []byte 类型，并进行原地替换，它不能接收一个字面量字符串，否则会发生严重错误

许可

go-extend 根据 MIT License 许可证授权，有关完整许可证文本，请参阅 LICENSE

go-extend's People

Contributors

Stargazers

Watchers

Forkers

robertluowen szyhf maxzhang qingshanyinyin bing127 huxiaoyugo aries5555 raceli wangy8961 crackercat pengio wangjuelong zhouyu260 dk-lockdown gaecom unclebig isgasho rainhan99 jecqiang tomy113 atnightly yp2800 daheige havoe xserve98 netkey zhangy1124 pyihe marlonfan seven1122 overtalk hh9net johnlion itwks bojiuyunkai lingling1420q mredencom sunct bigdot123456 chu108 imccie achilsh xyui newpurr javarobot234 matrix14159 carlziess adrainye a7600999 lovechiba withf jan29routerhuaile kavinbright undertreetech vxzhong dalonghahaha shikun0818 lz-freedom jiaonisi kotlin2018 zhanglei blueicesir ruanhanqin jangocheng ppbbgg110 silenceno1 wuqinqiang azhuang321 devenlu zoulingbin fbbin youbeiwuhuan 1920853199 xhcom-ui sanrentai kedoneyes youkebing hulaoan gavinyangs cute-angelia pythonlei jiawea zfg88287508 elonpue yfanswer wentaojin jasonmetal kyssion liujijun huangzhifengh vincent20101 wpecker changmu hzwangdechao niclausse zhusl www892 cctvbtx viagra0 ganlei333

go-extend's Issues

“动态评估bytes.Buffer的需求的容量，全局共享bytes.Buffer池” 这个pr存在性能测试问题，导致结果存在偏差

#16 在性能测试时，对SyncPool 测试时并没有对 Buffer 进行 Reset 操作，导致大量内存分配，测试结果没有参考性。

在完善测试用例后，以下测试结果并没有相较 sync.Pool 有明显优势，且可能对性能产生影响。

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/pool/benchmark
BenchmarkBufferPool
BenchmarkBufferPool-8                     943312              1065 ns/op               1 B/op          0 allocs/op
BenchmarkBufferSyncPool
BenchmarkBufferSyncPool-8                1000000              1032 ns/op               0 B/op          0 allocs/op
BenchmarkBufferFixedSizePool
BenchmarkBufferFixedSizePool-8          29174670                44.1 ns/op             0 B/op          0 allocs/op
BenchmarkBufferFixedSizeSyncPool
BenchmarkBufferFixedSizeSyncPool-8      38488425                28.1 ns/op             0 B/op          0 allocs/op
PASS
ok      github.com/thinkeridea/go-extend/pool/benchmark 5.236s

扩展 utf8 提供根据字符数量确定字符串索引位置

使用 utf8.DecodeRuneInString 逐个解析字符，使得比把字符串转为 []rune 运行效率更高，但是这并不是最好的解决方案，我需要一个方法在字符串中计算指定数量字符的索引位置，使得可以高效的利用字符串切片获得高效处理多字节字符的方案。

灵感来自 #5

IPString2Long和Long2IPString 能否支持IPV6？

改变 pool.NewBuffer 的行为，响应固定容量的BufferPool

pool.NewBuffer 在 #16 中引入的方法，实现根据实际使用场景动态评估默认 bytes.Buffer 容量的方法，因测试存在bug（在 #17 #18 中发现及修复）后被弃用，但是考虑 BufferPool 接口可以简化使用 sync.Pool 获取及响应 bytes.Buffer实例，故通过改变 pool.NewBuffer 的行为，响应一个独立的非共享的 BufferPool，每次调用都会返回新的 BufferPool。

加快内网地址检查，172.16~31.0.0/12 其掩码地址均为 172.16.0.0/12 存在重复

"10.0.0.0/8",
"169.254.0.0/16",
"172.16.0.0/12",
"172.17.0.0/12",
"172.18.0.0/12",
"172.19.0.0/12",
"172.20.0.0/12",
"172.21.0.0/12",
"172.22.0.0/12",
"172.23.0.0/12",
"172.24.0.0/12",
"172.25.0.0/12",
"172.26.0.0/12",
"172.27.0.0/12",
"172.28.0.0/12",
"172.29.0.0/12",
"172.30.0.0/12",
"172.31.0.0/12",
"192.168.0.0/16",

172.16~31.0.0/12 其掩码地址均为 172.16.0.0/12 存在重复。

使用直接对比ip段前两段数据检查，不使用 network.Contains 判断，在暂时不支持IPV6 的前提下，这种方法更加高效。

BUG: Round(169543.34596, -5) == 199999.99999999997, want 200000

exstrings.Reverse 性能改进

该方法收集于官网 How to write Go code 中的一个代码片段，因曾经面试遇到这个面试题而留心。

近期回答 Go Forum 中关于 [SOLVED] String size of 20 character 中字符串长度截取使用 []rune 类型与字符串类型转换，期望处理安全的 unicode 字符。

我对此方法提出了性能质疑，编写了基于 utf8.DecodeRuneInString 的计算版本，并做了性能测试相关回复在这里发现两个种方法性能差距惊人。

我想到了 go-extend 中的 exstrings.Reverse 方法也是用了类似的类型转换，所以我做了一个小的实验来测试不同实现的性能。

四舍五入函数存在精度问题

https://github.com/thinkeridea/go-extend/blob/main/exmath/round.go
四舍五入函数存在精度问题，如0.565保留两位小数输出的是0.56而不是0.57

建议采用更宽松的license,目前的gpl不利于库被更多项目使用

go的编译基本只能静态编译，这样gpl的传染性导致所有的代码都得开源，
这样其实不利于本库得到更多的使用，
相当多的go库都采用mit license