分类 软件开发 下的文章

大家常规的认知是,Go 程序中声明的类型越多,生成的二进制文件就越大。这个符合直觉,毕竟如果你写的代码不去操作定义的类型,那么定义一堆类型就没有意义了。然而,链接器的部分工作就是检测没有被程序引用的函数(比如说它们是一个库的一部分,其中只有一个子集的功能被使用),然后把它们从最后的编译产出中删除。常言道,“类型越多,二进制文件越大”,对于多数 Go 程序还是正确的。

本文中我会深入讲解在 Go 程序的上下文中“相等”的意义,以及为什么像这样的修改会对 Go 程序的大小有重大的影响。

定义两个值相等

Go 的语法定义了“赋值”和“相等”的概念。赋值是把一个值赋给一个标识符的行为。并不是所有声明的标识符都可以被赋值,如常量和函数就不可以。相等是通过检查标识符的内容是否相等来比较两个标识符的行为。

作为强类型语言,“相同”的概念从根源上被植入标识符的类型中。两个标识符只有是相同类型的前提下,才有可能相同。除此之外,值的类型定义了如何比较该类型的两个值。

例如,整型是用算数方法进行比较的。对于指针类型,是否相等是指它们指向的地址是否相同。映射和通道等引用类型,跟指针类似,如果它们指向相同的地址,那么就认为它们是相同的。

上面都是按位比较相等的例子,即值占用的内存的位模式是相同的,那么这些值就相等。这就是所谓的 memcmp,即内存比较,相等是通过比较两个内存区域的内容来定义的。

记住这个思路,我过会儿再来谈。

结构体相等

除了整型、浮点型和指针等标量类型,还有复合类型:结构体。所有的结构体以程序中的顺序被排列在内存中。因此下面这个声明:

type S struct {
    a, b, c, d int64
}

会占用 32 字节的内存空间;a 占用 8 个字节,b 占用 8 个字节,以此类推。Go 的规则说如果结构体所有的字段都是可以比较的,那么结构体的值就是可以比较的。因此如果两个结构体所有的字段都相等,那么它们就相等。

a := S{1, 2, 3, 4}
b := S{1, 2, 3, 4}
fmt.Println(a == b) // 输出 true

编译器在底层使用 memcmp 来比较 a 的 32 个字节和 b 的 32 个字节。

填充和对齐

然而,在下面的场景下过分简单化的按位比较的策略会返回错误的结果:

type S struct {
    a byte
    b uint64
    c int16
    d uint32
}

func main()
    a := S{1, 2, 3, 4}
    b := S{1, 2, 3, 4}
    fmt.Println(a == b) // 输出 true
}

编译代码后,这个比较表达式的结果还是 true,但是编译器在底层并不能仅依赖比较 ab 的位模式,因为结构体有填充

Go 要求结构体的所有字段都对齐。2 字节的值必须从偶数地址开始,4 字节的值必须从 4 的倍数地址开始,以此类推 1 。编译器根据字段的类型和底层平台加入了填充来确保字段都对齐。在填充之后,编译器实际上看到的是 2

type S struct {
    a byte
    _ [7]byte // 填充
    b uint64
    c int16
    _ [2]int16 // 填充
    d uint32
}

填充的存在保证了字段正确对齐,而填充确实占用了内存空间,但是填充字节的内容是未知的。你可能会认为在 Go 中 填充字节都是 0,但实际上并不是 — 填充字节的内容是未定义的。由于它们并不是被定义为某个确定的值,因此按位比较会因为分布在 s 的 24 字节中的 9 个填充字节不一样而返回错误结果。

Go 通过生成所谓的相等函数来解决这个问题。在这个例子中,s 的相等函数只比较函数中的字段略过填充部分,这样就能正确比较类型 s 的两个值。

类型算法

呵,这是个很大的设置,说明了为什么,对于 Go 程序中定义的每种类型,编译器都会生成几个支持函数,编译器内部把它们称作类型的算法。如果类型是一个映射的键,那么除相等函数外,编译器还会生成一个哈希函数。为了维持稳定,哈希函数在计算结果时也会像相等函数一样考虑诸如填充等因素。

凭直觉判断编译器什么时候生成这些函数实际上很难,有时并不明显,(因为)这超出了你的预期,而且链接器也很难消除没有被使用的函数,因为反射往往导致链接器在裁剪类型时变得更保守。

通过禁止比较来减小二进制文件的大小

现在,我们来解释一下 Brad 的修改。向类型添加一个不可比较的字段 3 ,结构体也随之变成不可比较的,从而强制编译器不再生成相等函数和哈希函数,规避了链接器对那些类型的消除,在实际应用中减小了生成的二进制文件的大小。作为这项技术的一个例子,下面的程序:

package main

import "fmt"

func main() {
    type t struct {
        // _ [0][]byte // 取消注释以阻止比较
        a byte
        b uint16
        c int32
        d uint64
    }
    var a t
    fmt.Println(a)
}

用 Go 1.14.2(darwin/amd64)编译,大小从 2174088 降到了 2174056,节省了 32 字节。单独看节省的这 32 字节似乎微不足道,但是考虑到你的程序中每个类型及其传递闭包都会生成相等和哈希函数,还有它们的依赖,这些函数的大小随类型大小和复杂度的不同而不同,禁止它们会大大减小最终的二进制文件的大小,效果比之前使用 -ldflags="-s -w" 还要好。

最后总结一下,如果你不想把类型定义为可比较的,可以在源码层级强制实现像这样的奇技淫巧,会使生成的二进制文件变小。


附录:在 Brad 的推动下,Cherry ZhangKeith Randall 已经在 Go 1.15 做了大量的改进,修复了最严重的故障,消除了无用的相等和哈希函数(虽然我猜想这也是为了避免这类 CL 的扩散)。

相关文章:

  1. Go 运行时如何高效地实现映射(不使用泛型)")
  2. 空结构体
  3. 填充很难
  4. Go 中有类型的 nil(2)

  1. 在 32 位平台上 int64unit64 的值可能不是按 8 字节对齐的,因为平台原生的是以 4 字节对齐的。查看 议题 599 了解内部详细信息。
  2. 32 位平台会在 ab 的声明中填充 _ [3]byte。参见前一条。
  3. Brad 使用的是[0]func(),但是所有能限制和禁止比较的类型都可以。添加了一个有 0 个元素的数组的声明后,结构体的大小和对齐不会受影响。

via: https://dave.cheney.net/2020/05/09/ensmallening-go-binaries-by-prohibiting-comparisons

作者:Dave Cheney 选题:lujun9972 译者:lxbwolf 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Codeigniter 是一个 PHP 框架,可以使公司进行开发具有灵活性和便捷性的高性能网站。

PHP Codeigniter 是一个开源框架,为商业应用提供易于使用的 PHP 编程语言和强大的编码工具。它还提供商务智能、服务器监视、开发和应用集成功能。这是一个相对冷清的项目,你很少听到它,但它功能强大,许多刚接触的开发人员都对此感到惊讶和耳目一新。

我在新加坡的一家在线学习服务提供商处使用 Codeigniter。我们提供的服务并不算常见,没有可以作为模板的默认功能集或现有后台管理系统,所以我需要一个能提供良好的、可靠的、可以建立在此基础上的原始材料。最初,我考虑用其他平台(如 Wordpress)用于我们的网站。但是,我决定使用 Codeigniter,因为它的灵活性,以及集成了在我们的补课匹配过程中需要的功能。

以下是打动我使用 Codeigniter 的原因:

  • 与 MySQL 数据库的集成 —— 主要功能是允许客户端浏览导师的数据库并添加导师,例如类似于电子商务平台的“购物车”。
  • 客户端界面系统 —— 用户可以登录来管理偏好并编辑详细信息,修改所教的科目、旅游的地区、手机号码、地址等。
  • 定制的管理员面板 —— 管理员可以使用定制的管理面板访问客户提交的资料,它与客户服务功能集成在一起,因此管理员可以单独跟进。
  • 付款系统 —— 管理面板带有与 Paypal 集成的发票和付款网关。
  • CMS 编辑器界面 —— 管理员能够编辑博客和文章中的文本和图像,以及添加新页面。

该项目花费了大约六个月的时间来完成,另外花了两个月的调试时间。如果我需要从头开始构建所有,或者尝试重新设计现有的框架以满足我们的需求,那将花费更长的时间,而且可能最终无法满足客户需求。

功能和优点

PHP Codeigniter还有很多吸引开发者的功能,包括错误处理和代码格式化,这些功能在各种编码情景下都非常有用。它支持模板,可用于向现有网站添加功能或生成新网站。有许多基于 web 系统商业需要的功能,包括使用自定义标签。即使没有编程经验的普通开发人员也可以使用大多数工具。

Codeigniter 的主要功能是:

  • XML 核心服务,
  • HTTP/FTP 核心服务
  • AppData 和 PHP 沙箱功能
  • XSLT 和 HTML 模板
  • 加密的信息传输
  • PCM Codeigniter 服务器监控
  • 应用集成
  • 文件传输协议(FTP)
  • 服务台支持
  • Apache POI(用于托管网站的内容管理基础架构)

兼容性

Codeigniter 与许多领先的软件程序兼容,例如 PHP、MySQL、MariaDBphpMyAdminApache、OpenBSD、XSLT、SQLite 等。许多公司更喜欢使用 Codeigniter 产品来满足网站要求,因为它们易于使用和集成。如果你不想创建自己的网站,你可以找到许多提供自定义 Web 开发服务的开发人员和设计机构。

安全

Codeigniter 还通过 SSL 加密提供数据安全性。加密可以保护数据免受入侵者和防火墙外部威胁的侵害。数据存储功能还允许对公司网站进行安全审核。

其它功能

一家优秀的 PHP Web 开发公司会使用几种高级技术和第三方技术,例如 XML 和 PHP。它为企业提供了一个完整的平台,可以开发出具有看起来专业的、好用的商业网站。Codeigniter 使得第三方技术的使用变得容易,并可以与常见的 Web 开发软件一起使用。这使得 Web 公司可以轻松地使用所选模块创建网站。大多数 PHP 开发者也为个人提供支持和培训服务。

使用 PHP 框架 Codeigniter

Codeigniter 给企业提供了完整的 PHP 开发包,它将提供强大的功能、灵活性和性能完美结合在一起。到目前为止,我很满意我们的网站,并不断地升级和添加新的功能。并不断升级和增加新的功能。我期待着发现我们的网站还能用 Codeigniter 做些什么。你也是这样么?


via: https://opensource.com/article/20/5/codeigniter

作者:Wee Ben Sen 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

让大家觉得你一次就能写出完美的代码,并让你的补丁更容易审核和合并。

软件开发是混乱的。有很多错误的转折、有需要修复的错别字、有需要修正的错误、有需要稍后纠正的临时和粗陋的代码,还有在以后的开发过程中发现一次又一次的问题。有了版本控制,在创建“完美”的最终产品(即准备提交给上游的补丁)的过程中,你会有一个记录着每一个错误转折和修正的原始记录。就像电影中的花絮一样,它们会让人有点尴尬,有时也会让人觉得好笑。

如果你使用版本控制来定期保存你的工作线索,然后当你准备提交审核的东西时,又可以隐藏所有这些私人草稿工作,并只提交一份单一的、完美的补丁,那不是很好吗?git rebase -i,是重写历史记录的完美方法,可以让大家觉得你一次就写出了完美的代码!

git rebase 的作用是什么?

如果你不熟悉 Git 的复杂性,这里简单介绍一下。在幕后,Git 将项目的不同版本与唯一标识符关联起来,这个标识符由父节点的唯一标识符的哈希以及新版本与其父节点的差异组成。这样就形成了一棵修订树,每个签出项目的人都会得到自己的副本。不同的人可以把项目往不同的方向发展,每个方向都可能从不同的分支点开始。

 title=

左边是 origin 版本库中的主分支,右边是你个人副本中的私有分支。

有两种方法可以将你的工作与原始版本库中的主分支整合起来:一种是使用合并:git merge,另一种是使用变基:git rebase。它们的工作方式非常不同。

当你使用 git merge 时,会在主分支(master)上创建一个新的提交,其中包括所有来自原始位置(origin)的修改和所有本地的修改。如果有任何冲突(例如,如果别人修改了你也在修改的文件),则将这些冲突标记出来,并且你有机会在将这个“合并提交”提交到本地版本库之前解决这些冲突。当你将更改推送回父版本库时,所有的本地工作都会以分支的形式出现在 Git 版本库的其他用户面前。

但是 git rebase 的工作方式不同。它会回滚你的提交,并从主分支(master)的顶端再次重放这些提交。这导致了两个主要的变化。首先,由于你的提交现在从一个不同的父节点分支出来,它们的哈希值会被重新计算,并且任何克隆了你的版本库的人都可能得到该版本库的一个残破副本。第二,你没有“合并提交”,所以在将更改重放到主分支上时会识别出任何合并冲突,因此,你需要在进行 变基 rebase 之前先修复它们。现在,当你现在推送你的修改时,你的工作不会出现在分支上,并且看起来像是你是在主分支的最新的提交上写入了所有的修改。

 title=

合并提交(左)保留了历史,而变基(右)重写历史。

然而,这两种方式都有一个缺点:在你准备好分享代码之前,每个人都可以看到你在本地处理问题时的所有涂鸦和编辑。这就是 git rebase--interactive(或简写 -i)标志发挥作用的地方。

git rebase -i 登场

git rebase 的最大优点是它可以重写历史。但是,为什么仅止于假装你从后面的点分支出来呢?有一种更进一步方法可以重写你是如何准备就绪这些代码的:git rebase -i,即交互式的 git rebase

这个功能就是 Git 中的 “魔术时光机” 功能。这个标志允许你在做变基时对修订历史记录进行复杂的修改。你可以隐藏你的错误! 将许多小的修改合并到一个崭新的功能补丁中! 重新排列修改历史记录中的显示顺序!

 title=

当你运行 git rebase -i 时,你会进入一个编辑器会话,其中列出了所有正在被变基的提交,以及可以对其执行的操作的多个选项。默认的选择是选择(Pick)。

  • Pick:会在你的历史记录中保留该提交。
  • Reword:允许你修改提交信息,可能是修复一个错别字或添加其它注释。
  • Edit:允许你在重放分支的过程中对提交进行修改。
  • Squash:可以将多个提交合并为一个。
  • 你可以通过在文件中移动来重新排序提交。

当你完成后,只需保存最终结果,变基操作就会执行。在你选择修改提交的每个阶段(无论是用 rewordeditsquash 还是发生冲突时),变基都会停止,并允许你在继续提交之前进行适当的修改。

上面这个例子的结果是 “One-liner bug fix” 和 “Integate new header everywhere” 被合并到一个提交中,而 “New header for docs website” 和 “D'oh - typo. Fixed” 合并到另一个提交中。就像变魔术一样,其他提交的工作还在你的分支中,但相关的提交已经从你的历史记录中消失了!

这使得使用 git send-email 或者用你新整理好的补丁集在父版本库中创建一个拉取请求,然后来提交一个干净的补丁给上游项目变得很容易。这有很多好处,包括让你的代码更容易审核,更容易接受,也更容易合并。


via: https://opensource.com/article/20/4/git-rebase-i

作者:Dave Neary 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

上一篇文章中我论述了 叶子内联 leaf inlining 是怎样让 Go 编译器减少函数调用的开销的,以及延伸出了跨函数边界的优化的机会。本文中,我要论述内联的限制以及叶子内联与 栈中内联 mid-stack inlining 的对比。

内联的限制

把函数内联到它的调用处消除了调用的开销,为编译器进行其他的优化提供了更好的机会,那么问题来了,既然内联这么好,内联得越多开销就越少,为什么不尽可能多地内联呢?

内联可能会以增加程序大小换来更快的执行时间。限制内联的最主要原因是,创建许多函数的内联副本会增加编译时间,并导致生成更大的二进制文件的边际效应。即使把内联带来的进一步的优化机会考虑在内,太激进的内联也可能会增加生成的二进制文件的大小和编译时间。

内联收益最大的是小函数,相对于调用它们的开销来说,这些函数做很少的工作。随着函数大小的增长,函数内部做的工作与函数调用的开销相比省下的时间越来越少。函数越大通常越复杂,因此优化其内联形式相对于原地优化的好处会减少。

内联预算

在编译过程中,每个函数的内联能力是用内联预算计算的 1 。开销的计算过程可以巧妙地内化,像一元和二元等简单操作,在 抽象语法数 Abstract Syntax Tree (AST)中通常是每个节点一个单位,更复杂的操作如 make 可能单位更多。考虑下面的例子:

package main

func small() string {
    s := "hello, " + "world!"
    return s
}

func large() string {
    s := "a"
    s += "b"
    s += "c"
    s += "d"
    s += "e"
    s += "f"
    s += "g"
    s += "h"
    s += "i"
    s += "j"
    s += "k"
    s += "l"
    s += "m"
    s += "n"
    s += "o"
    s += "p"
    s += "q"
    s += "r"
    s += "s"
    s += "t"
    s += "u"
    s += "v"
    s += "w"
    s += "x"
    s += "y"
    s += "z"
    return s
}

func main() {
    small()
    large()
}

使用 -gcflags=-m=2 参数编译这个函数能让我们看到编译器分配给每个函数的开销:

% go build -gcflags=-m=2 inl.go
# command-line-arguments
./inl.go:3:6: can inline small with cost 7 as: func() string { s := "hello, world!"; return s }
./inl.go:8:6: cannot inline large: function too complex: cost 82 exceeds budget 80
./inl.go:38:6: can inline main with cost 68 as: func() { small(); large() }
./inl.go:39:7: inlining call to small func() string { s := "hello, world!"; return s }

编译器根据函数 func small() 的开销(7)决定可以对它内联,而 func large() 的开销太大,编译器决定不进行内联。func main() 被标记为适合内联的,分配了 68 的开销;其中 small 占用 7,调用 small 函数占用 57,剩余的(4)是它自己的开销。

可以用 -gcflag=-l 参数控制内联预算的等级。下面是可使用的值:

  • -gcflags=-l=0 默认的内联等级。
  • -gcflags=-l(或 -gcflags=-l=1)取消内联。
  • -gcflags=-l=2-gcflags=-l=3 现在已经不使用了。和 -gcflags=-l=0 相比没有区别。
  • -gcflags=-l=4 减少非叶子函数和通过接口调用的函数的开销。 2

不确定语句的优化

一些函数虽然内联的开销很小,但由于太复杂它们仍不适合进行内联。这就是函数的不确定性,因为一些操作的语义在内联后很难去推导,如 recoverbreak。其他的操作,如 selectgo 涉及运行时的协调,因此内联后引入的额外的开销不能抵消内联带来的收益。

不确定的语句也包括 forrange,这些语句不一定开销很大,但目前为止还没有对它们进行优化。

栈中函数优化

在过去,Go 编译器只对叶子函数进行内联 —— 只有那些不调用其他函数的函数才有资格。在上一段不确定的语句的探讨内容中,一次函数调用就会让这个函数失去内联的资格。

进入栈中进行内联,就像它的名字一样,能内联在函数调用栈中间的函数,不需要先让它下面的所有的函数都被标记为有资格内联的。栈中内联是 David Lazar 在 Go 1.9 中引入的,并在随后的版本中做了改进。这篇文稿深入探究了保留栈追踪行为和被深度内联后的代码路径里的 runtime.Callers 的难点。

在前面的例子中我们看到了栈中函数内联。内联后,func main() 包含了 func small() 的函数体和对 func large() 的一次调用,因此它被判定为非叶子函数。在过去,这会阻止它被继续内联,虽然它的联合开销小于内联预算。

栈中内联的最主要的应用案例就是减少贯穿函数调用栈的开销。考虑下面的例子:

package main

import (
    "fmt"
    "strconv"
)

type Rectangle struct {}

//go:noinline
func (r *Rectangle) Height() int {
    h, _ := strconv.ParseInt("7", 10, 0)
    return int(h)
}

func (r *Rectangle) Width() int {
    return 6
}

func (r *Rectangle) Area() int { return r.Height() * r.Width() }

func main() {
    var r Rectangle
    fmt.Println(r.Area())
}

在这个例子中, r.Area() 是个简单的函数,调用了两个函数。r.Width() 可以被内联,r.Height() 这里用 //go:noinline 指令标注了,不能被内联。 3

% go build -gcflags='-m=2' square.go                                                                                                          
# command-line-arguments
./square.go:12:6: cannot inline (*Rectangle).Height: marked go:noinline                                                                               
./square.go:17:6: can inline (*Rectangle).Width with cost 2 as: method(*Rectangle) func() int { return 6 }
./square.go:21:6: can inline (*Rectangle).Area with cost 67 as: method(*Rectangle) func() int { return r.Height() * r.Width() }                       
./square.go:21:61: inlining call to (*Rectangle).Width method(*Rectangle) func() int { return 6 }                                                     
./square.go:23:6: cannot inline main: function too complex: cost 150 exceeds budget 80                        
./square.go:25:20: inlining call to (*Rectangle).Area method(*Rectangle) func() int { return r.Height() * r.Width() }
./square.go:25:20: inlining call to (*Rectangle).Width method(*Rectangle) func() int { return 6 }

由于 r.Area() 中的乘法与调用它的开销相比并不大,因此内联它的表达式是纯收益,即使它的调用的下游 r.Height() 仍是没有内联资格的。

快速路径内联

关于栈中内联的效果最令人吃惊的例子是 2019 年 Carlo Alberto Ferraris 通过允许把 sync.Mutex.Lock() 的快速路径(非竞争的情况)内联到它的调用方来提升它的性能。在这个修改之前,sync.Mutex.Lock() 是个很大的函数,包含很多难以理解的条件,使得它没有资格被内联。即使锁可用时,调用者也要付出调用 sync.Mutex.Lock() 的代价。

Carlo 把 sync.Mutex.Lock() 分成了两个函数(他自己称为 外联 outlining )。外部的 sync.Mutex.Lock() 方法现在调用 sync/atomic.CompareAndSwapInt32() 且如果 CAS( 比较并交换 Compare and Swap )成功了之后立即返回给调用者。如果 CAS 失败,函数会走到 sync.Mutex.lockSlow() 慢速路径,需要对锁进行注册,暂停 goroutine。 4

% go build -gcflags='-m=2 -l=0' sync 2>&1 | grep '(*Mutex).Lock'
../go/src/sync/mutex.go:72:6: can inline (*Mutex).Lock with cost 69 as: method(*Mutex) func() { if "sync/atomic".CompareAndSwapInt32(&m.state, 0, mutexLocked) { if race.Enabled {  }; return  }; m.lockSlow() }

通过把函数分割成一个简单的不能再被分割的外部函数,和(如果没走到外部函数就走到的)一个处理慢速路径的复杂的内部函数,Carlo 组合了栈中函数内联和编译器对基础操作的支持,减少了非竞争锁 14% 的开销。之后他在 sync.RWMutex.Unlock() 重复这个技巧,节省了另外 9% 的开销。

相关文章:

  1. Go 中的内联优化
  2. goroutine 的栈为什么会无限增长?
  3. 栈追踪和 errors 包
  4. 零值是什么,为什么它很有用?

  1. 不同发布版本中,在考虑该函数是否适合内联时,Go 编译器对同一函数的预算是不同的。
  2. 时刻记着编译器的作者警告过“更高的内联等级(比 -l 更高)可能导致错误或不被支持”。 Caveat emptor。
  3. 编译器有足够的能力来内联像 strconv.ParseInt 的复杂函数。作为一个实验,你可以尝试去掉 //go:noinline 注释,使用 -gcflags=-m=2 编译后观察。
  4. race.Enable 表达式是通过传递给 go 工具的 -race 参数控制的一个常量。对于普通编译,它的值是 false,此时编译器可以完全省略代码路径。

via: https://dave.cheney.net/2020/05/02/mid-stack-inlining-in-go

作者:Dave Cheney 选题:lujun9972 译者:lxbwolf 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Git Extras 版本库包含了 60 多个脚本,它们是 Git 基本功能的补充。以下是如何安装、使用和贡献的方法。

2005 年,Linus Torvalds 创建了 Git,以取代他之前用于维护 Linux 内核的分布式源码控制管理的专有解决方案。从那时起,Git 已经成为开源和云原生开发团队的主流版本控制解决方案。

但即使是像 Git 这样功能丰富的应用程序,也没有人们想要或需要的每个功能,所以会有人花大力气去创建这些缺少的功能。就 Git 而言,这个人就是 TJ Holowaychuk。他的 Git Extras 项目承载了 60 多个“附加功能”,这些功能扩展了 Git 的基本功能。

使用 Git 附加功能

下面介绍一下如何使用四种最受欢迎的 Git 附加功能。

git-ignore

git ignore 是一个方便的附加功能,它可以让你手动添加文件类型和注释到 .git-ignore 文件中,而不需要打开文本编辑器。它可以操作你的个人用户帐户的全局忽略文件和单独用于你正在工作的版本库中的忽略文件。

在不提供参数的情况下执行 git ignore 会先列出全局忽略文件,然后是本地的忽略文件。

$ git ignore
Global gitignore: /home/alice/.gitignore
# Numerous always-ignore extensions
*.diff
*.err
*.orig
*.rej
*.swo
*.swp
*.vi
*~
*.sass-cache

# OS or Editor folders
Thumbs.db
---------------------------------
Local gitignore: .gitignore
nbproject

git-info

git info 可以检索你所需要的所有信息,以获取你正在使用的版本库的上下文信息。它包括远程 URL、远程分支、本地分支、配置信息和最后一次的提交信息。

$ git info

## Remote URLs:

origin      [email protected]:sampleAuthor/git-extras.git (fetch)
origin      [email protected]:sampleAuthor/git-extras.git (push)

## Remote Branches:

origin/HEAD -> origin/master
origin/myBranch

## Local Branches:

myBranch
* master

## Most Recent Commit:

commit e3952df2c172c6f3eb533d8d0b1a6c77250769a7
Author: Sample Author <[email protected]>

Added git-info command.

Type ´git log´ for more commits, or ´git show <commit id>´ for full commit details.

## Configuration (.git/config):

color.diff=auto
color.status=auto
color.branch=auto
user.name=Sample Author
[email protected]
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
[email protected]:mub/git-extras.git
branch.master.remote=origin
branch.master.merge=refs/heads/master

git-mr 和 git-pr

这些附加功能的作用类似,工作方式也基本相同。

  • git mr 检出来自 GitLab 的合并请求。
  • git pr 检出来自 GitHub 的拉取请求。

无论是哪种情况,你只需要合并请求号/拉取请求号或完整的 URL,它就会抓取远程引用,检出分支,并调整配置,这样 Git 就知道要替换哪个分支了。

$ git mr 51
From gitlab.com:owner/repository
 * [new ref]         refs/merge-requests/51/head -> mr/51
Switched to branch 'mr/51'

git-release

通过将 committagpush 合并到一个命令中,git release 可以节省大量的按键来执行这三个命令,而这三个命令往往是依次运行的。

要用特定的 <tagname> 和自定义消息提交:

$ git release 0.1.0 -m <+ powerful feature added>

其他附加功能

这只是该版本库中 60 多个 Git 附加功能中的四个命令。要访问 Git Extras 中的全部命令,请查看该源代码库中的 Commands.md 文件,或者在安装 Git Extras 后运行以下命令。

$ git extras --help

安装 Git 附加功能

使用 Git 附加功能的主要前提是安装了 Git 的命令行版本。如果你打算从源码中构建,还需要有额外的工具(例如:make)。

如果你使用的是最新版本的 macOS,那么 Git 附加功能的安装最好使用 Homebrew(和大多数开源工具一样)。

$ brew install git-extras

在 Linux 上,每个平台原生的包管理器中都包含有 Git Extras。有时,你需要启用额外的仓库,比如在 CentOS 上的 EPEL,然后运行一条命令。

$ sudo yum install git-extras

其他 Linux 发行版、BSD 和其他平台的完整安装说明可以在该版本库的 Installation.md 文件中找到。

贡献

你是否认为 Git 中有缺少的功能,并且已经构建了一个脚本来处理它?为什么不把它作为 Git Extras 发布版的一部分,与全世界分享呢?

要做到这一点,请将该功能贡献到 Git Extras 仓库中。更多具体细节请参见仓库中的 CONTRIBUTING.md 文件,但基本的操作方法很简单:

  1. 创建一个处理该功能的 Bash 脚本。
  2. 创建一个基本的 man 文件,让大家知道如何使用它。
  3. 更新命令列表和补完脚本,让人们知道这个功能的存在。
  4. 运行完整性检查,确保你没有破坏任何东西。
  5. 为你的功能创建一个拉取请求。

向 Git Extras 贡献贡献,会让你的 Git 用户的生活更轻松一些。你可以在项目的 README 中了解更多。


via: https://opensource.com/article/20/4/git-extras

作者:Vince Power 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

本文讨论 Go 编译器是如何实现内联的,以及这种优化方法如何影响你的 Go 代码。

请注意:本文重点讨论 gc,这是来自 golang.org 的事实标准的 Go 编译器。讨论到的概念可以广泛适用于其它 Go 编译器,如 gccgo 和 llgo,但它们在实现方式和功效上可能有所差异。

内联是什么?

内联 inlining 就是把简短的函数在调用它的地方展开。在计算机发展历程的早期,这个优化是由程序员手动实现的。现在,内联已经成为编译过程中自动实现的基本优化过程的其中一步。

为什么内联很重要?

有两个原因。第一个是它消除了函数调用本身的开销。第二个是它使得编译器能更高效地执行其他的优化策略。

函数调用的开销

在任何语言中,调用一个函数 1 都会有消耗。把参数编组进寄存器或放入栈中(取决于 ABI),在返回结果时的逆反过程都会有开销。引入一次函数调用会导致程序计数器从指令流的一点跳到另一点,这可能导致管道滞后。函数内部通常有 前置处理 preamble ,需要为函数执行准备新的栈帧,还有与前置相似的 后续处理 epilogue ,需要在返回给调用方之前释放栈帧空间。

在 Go 中函数调用会消耗额外的资源来支持栈的动态增长。在进入函数时,goroutine 可用的栈空间与函数需要的空间大小进行比较。如果可用空间不同,前置处理就会跳到 运行时 runtime 的逻辑中,通过把数据复制到一块新的、更大的空间的来增长栈空间。当这个复制完成后,运行时就会跳回到原来的函数入口,再执行栈空间检查,现在通过了检查,函数调用继续执行。这种方式下,goroutine 开始时可以申请很小的栈空间,在有需要时再申请更大的空间。 2

这个检查消耗很小,只有几个指令,而且由于 goroutine 的栈是成几何级数增长的,因此这个检查很少失败。这样,现代处理器的分支预测单元可以通过假定检查肯定会成功来隐藏栈空间检查的消耗。当处理器预测错了栈空间检查,不得不放弃它在推测性执行所做的操作时,与为了增加 goroutine 的栈空间运行时所需的操作消耗的资源相比,管道滞后的代价更小。

虽然现代处理器可以用预测性执行技术优化每次函数调用中的泛型和 Go 特定的元素的开销,但那些开销不能被完全消除,因此在每次函数调用执行必要的工作过程中都会有性能消耗。一次函数调用本身的开销是固定的,与更大的函数相比,调用小函数的代价更大,因为在每次调用过程中它们做的有用的工作更少。

因此,消除这些开销的方法必须是要消除函数调用本身,Go 的编译器就是这么做的,在某些条件下通过用函数的内容来替换函数调用来实现。这个过程被称为内联,因为它在函数调用处把函数体展开了。

改进的优化机会

Cliff Click 博士把内联描述为现代编译器做的优化措施,像常量传播(LCTT 译注:此处作者笔误,原文为 constant proportion,修正为 constant propagation)和死代码消除一样,都是编译器的基本优化方法。实际上,内联可以让编译器看得更深,使编译器可以观察调用的特定函数的上下文内容,可以看到能继续简化或彻底消除的逻辑。由于可以递归地执行内联,因此不仅可以在每个独立的函数上下文处进行这种优化决策,也可以在整个函数调用链中进行。

实践中的内联

下面这个例子可以演示内联的影响:

package main

import "testing"

//go:noinline
func max(a, b int) int {
    if a > b {
        return a
    }
    return b
}

var Result int

func BenchmarkMax(b *testing.B) {
    var r int
    for i := 0; i < b.N; i++ {
        r = max(-1, i)
    }
    Result = r
}

运行这个基准,会得到如下结果: 3

% go test -bench=. 
BenchmarkMax-4   530687617         2.24 ns/op

在我的 2015 MacBook Air 上 max(-1, i) 的耗时约为 2.24 纳秒。现在去掉 //go:noinline 编译指令,再看下结果:

% go test -bench=. 
BenchmarkMax-4   1000000000         0.514 ns/op

从 2.24 纳秒降到了 0.51 纳秒,或者从 benchstat 的结果可以看出,有 78% 的提升。

% benchstat {old,new}.txt
name   old time/op  new time/op  delta
Max-4  2.21ns ± 1%  0.49ns ± 6%  -77.96%  (p=0.000 n=18+19)

这个提升是从哪儿来的呢?

首先,移除掉函数调用以及与之关联的前置处理 4 是主要因素。把 max 函数的函数体在调用处展开,减少了处理器执行的指令数量并且消除了一些分支。

现在由于编译器优化了 BenchmarkMax,因此它可以看到 max 函数的内容,进而可以做更多的提升。当 max 被内联后,BenchmarkMax 呈现给编译器的样子,看起来是这样的:

func BenchmarkMax(b *testing.B) {
    var r int
    for i := 0; i < b.N; i++ {
        if -1 > i {
            r = -1
        } else {
            r = i
        }
    }
    Result = r
}

再运行一次基准,我们看一下手动内联的版本和编译器内联的版本的表现:

% benchstat {old,new}.txt
name   old time/op  new time/op  delta
Max-4  2.21ns ± 1%  0.48ns ± 3%  -78.14%  (p=0.000 n=18+18)

现在编译器能看到在 BenchmarkMax 里内联 max 的结果,可以执行以前不能执行的优化措施。例如,编译器注意到 i 初始值为 0,仅做自增操作,因此所有与 i 的比较都可以假定 i 不是负值。这样条件表达式 -1 > i 永远不是 true 5

证明了 -1 > i 永远不为 true 后,编译器可以把代码简化为:

func BenchmarkMax(b *testing.B) {
    var r int
    for i := 0; i < b.N; i++ {
        if false {
            r = -1
        } else {
            r = i
        }
    }
    Result = r
}

并且因为分支里是个常量,编译器可以通过下面的方式移除不会走到的分支:

func BenchmarkMax(b *testing.B) {
    var r int
    for i := 0; i < b.N; i++ {
        r = i
    }
    Result = r
}

这样,通过内联和由内联解锁的优化过程,编译器把表达式 r = max(-1, i)) 简化为 r = i

内联的限制

本文中我论述的内联称作 叶子内联 leaf inlining :把函数调用栈中最底层的函数在调用它的函数处展开的行为。内联是个递归的过程,当把函数内联到调用它的函数 A 处后,编译器会把内联后的结果代码再内联到 A 的调用方,这样持续内联下去。例如,下面的代码:

func BenchmarkMaxMaxMax(b *testing.B) {
    var r int
    for i := 0; i < b.N; i++ {
        r = max(max(-1, i), max(0, i))
    }
    Result = r
}

与之前的例子中的代码运行速度一样快,因为编译器可以对上面的代码重复地进行内联,也把代码简化到 r = i 表达式。

下一篇文章中,我会论述当 Go 编译器想要内联函数调用栈中间的某个函数时选用的另一种内联策略。最后我会论述编译器为了内联代码准备好要达到的极限,这个极限 Go 现在的能力还达不到。

相关文章:

  1. 使 Go 变快的 5 件事
  2. 为什么 Goroutine 的栈空间会无限增长?
  3. Go 中怎么写基准测试
  4. Go 中隐藏的编译指令

  1. 在 Go 中,一个方法就是一个有预先定义的形参和接受者的函数。假设这个方法不是通过接口调用的,调用一个无消耗的函数所消耗的代价与引入一个方法是相同的。
  2. 在 Go 1.14 以前,栈检查的前置处理也被垃圾回收器用于 STW,通过把所有活跃的 goroutine 栈空间设为 0,来强制它们切换为下一次函数调用时的运行时状态。这个机制最近被替换为一种新机制,新机制下运行时可以不用等 goroutine 进行函数调用就可以暂停 goroutine。
  3. 我用 //go:noinline 编译指令来阻止编译器内联 max。这是因为我想把内联 max 的影响与其他影响隔离开,而不是用 -gcflags='-l -N' 选项在全局范围内禁止优化。关于 //go: 注释在这篇文章中详细论述。
  4. 你可以自己通过比较 go test -bench=. -gcflags=-S 有无 //go:noinline 注释时的不同结果来验证一下。
  5. 你可以用 -gcflags=-d=ssa/prove/debug=on 选项来自己验证一下。

via: https://dave.cheney.net/2020/04/25/inlining-optimisations-in-go

作者:Dave Cheney 选题:lujun9972 译者:lxbwolf 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出