先看标准库中的time package benchmark的指标变化：
1 | Changes in the time package benchmarks: |
数据来源： https://github.com/golang/go/commit/6becb033341602f2df9d7c55cc23e64b925bbee2
从基准测试结果中可以看到，After函数从老版本的1.63ms直接下降到了0.11ms，提升相当恐怖。
我个人对于此次优化的粗浅理解是：
为什么要内存对齐
CPU访问内存时，并不是逐个字节访问，而是以字长（word size）为单位访问。比如32位的CPU，字长为4字节，那么CPU访问内存的单位也是4字节。
这么设计的目的，是减少CPU访问内存的次数，加大CPU访问内存的吞吐量。比如同样读取8个字节的数据，一次读取4个字节那么只需要读取2次。
下面我们来看看，编写程序时，变量在内存中是否按内存对齐的差异。假设我们有如下结构体：
聊聊base64编码
base64的作用
二进制的数据，每个字符的取值范围都是[0, 255]，作为ascii码解析时，只有部分可打印。
比如，我用文本编辑器vim打开一张jpeg图片，会发现内容是乱码。以下是头两行数据：
1 | ÿØÿà^@^PJFIF^@^A^A^@^@^A^@^A^@^@ÿÛ^@C^@^F^D^E^F^E^D^F^F^E^F^G^G^F^H |
我在vim下输入:%!xxd，可以查看二进制数据对应的十六进值。以下是头两行数据：
1 | 00000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001 ......JFIF...... |
注意，下面的两行和上面的两行内容长度不一定是相同的。上面的数据是遇到ascii码为换行时换行，下面的数据是每16个字节换行。
比较上下两份数据，可以看到JFIF在上面也打印了，在下面的右半部分也打印了。说明他们的数据源确实是同一份，只是展示方式不同。
显然，如果我想肉眼看这份二进制数据，或者说作为文本拷贝这份数据，16进制的格式要优于二进制ascii码格式。
但是，16进制表示法，需要两个字节才能表示表示原始数据的一个字节。比如4a464946表示JFIF。即大小增加了一倍。
有点大？于是，有人发明了base64算法。它保持了编码后可打印特性的同时，大小只增加1/3。
base64算法原理
老弟在吗，我怀疑Go标准库中的二分查找有bug！
“老弟在吗，我怀疑Go标准库中的二分查找有bug！”
“老哥别慌，源码之前没有秘密，你坐下听我吹吹c++的牛逼。。”
下面这段Go代码，你觉得index的结果是多少？
1 | arr := []int{1, 3, 5, 7} |