- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
一转眼go1.23都快发布了,时间过得真快.
不过今天我们把时间倒流回三年半之前,来关注一个在go1.16引入的关于处理目录时的优化.
对于go1.16的新变化,大家印象最深的可能是io包的大规模重构,但这个重构实际上还引进了一个优化,这篇文章要说的就是这个优化.
本文默认Linux环境,不过这个优化在BSD系统上也是通用的.
遍历目录是个很常见的需求,尤其是对于有大量文件的目录来说,遍历的性能直接关系到了整体程序的性能.
go1.16对于遍历目录增加了几个新接口:os.ReadDir,(*os.File).ReadDir,filepath.WalkDir.
这几个接口最大的特征是对目录项使用fs.DirEntry表示而不是os.FileInfo。fs.DirEntry是一个接口,它提供了类似os.FileInfo的方法:
type DirEntry interface {
Name() string
IsDir() bool
Type() FileMode
Info() (FileInfo, error)
}
它还提供了一个叫Info的方法以便获得os.FileInfo.
这个接口有什么神奇的呢?我们看下性能测试:
func IterateDir(path string) int {
// go1.16 的 os.ReadDir 就是这么实现的,为了测试我们把它展开成对(*os.File).ReadDir的调用
f, err := os.Open(path)
if err != nil {
panic(err)
}
defer f.Close()
files, err := f.ReadDir(-1)
if err != nil {
panic(err)
}
length := 0
for _, finfo := range files {
length = max(length, len(finfo.Name()))
}
return length
}
func IterateDir2(path string) int {
// 1.16之前遍历目录的常用方法之一
f, err := os.Open(path)
if err != nil {
panic(err)
}
defer f.Close()
files, err := f.Readdir(-1)
if err != nil {
panic(err)
}
length := 0
for _, finfo := range files {
length = max(length, len(finfo.Name()))
}
return length
}
func BenchmarkIter1(b *testing.B) {
for range b.N {
IterateDir("../test")
}
}
func BenchmarkIter2(b *testing.B) {
for range b.N {
IterateDir2("../test")
}
}
test目录是一个有5000个文件的位于Btrfs文件系统上的目录,我们的测试用例会遍历目录并找出名字最长的文件的文件名长度.
这是测试结果:
可以看到优化后的遍历比原先的快了480%。换了个函数为什么就会有这么大的提升?想知道答案的话就继续看吧.
继续深入前我们先看看老的接口是怎么获取到目录里的文件信息的。答案是遍历目录拿到路径,然后调用os.Lstat获取完整的文件信息:
func (f *File) Readdir(n int) ([]FileInfo, error) {
if f == nil {
return nil, ErrInvalid
}
_, _, infos, err := f.readdir(n, readdirFileInfo)
if infos == nil {
// Readdir has historically always returned a non-nil empty slice, never nil,
// even on error (except misuse with nil receiver above).
// Keep it that way to avoid breaking overly sensitive callers.
infos = []FileInfo{}
}
return infos, err
}
这个f.readdir会根据第二个参数的值来改变自己的行为,根据值不同它会遵循1.16前老代码的行为或者采用新的优化方法。这个函数不同系统上的实现也不同,我们选则*nix系统上的实现看看:
func (f *File) readdir(n int, mode readdirMode) (names []string, dirents []DirEntry, infos []FileInfo, err error) {
...
for n != 0 {
// 使用系统调用获得目录项的数据
// 目录项的元信息一般是存储在目录本身的数据里的,所以读这些信息和读普通文件很类似
if d.bufp >= d.nbuf {
d.bufp = 0
var errno error
d.nbuf, errno = f.pfd.ReadDirent(*d.buf)
runtime.KeepAlive(f)
if errno != nil {
return names, dirents, infos, &PathError{Op: "readdirent", Path: f.name, Err: errno}
}
if d.nbuf <= 0 {
break // EOF
}
}
buf := (*d.buf)[d.bufp:d.nbuf]
reclen, ok := direntReclen(buf)
if !ok || reclen > uint64(len(buf)) {
break
}
// 注意这行
rec := buf[:reclen]
if mode == readdirName {
names = append(names, string(name))
} else if mode == readdirDirEntry {
// 这里的代码后面再看
} else {
info, err := lstat(f.name + "/" + string(name))
if IsNotExist(err) {
// File disappeared between readdir + stat.
// Treat as if it didn't exist.
continue
}
if err != nil {
return nil, nil, infos, err
}
infos = append(infos, info)
}
}
if n > 0 && len(names)+len(dirents)+len(infos) == 0 {
return nil, nil, nil, io.EOF
}
return names, dirents, infos, nil
}
ReadDirent对应的是Linux上的系统调用getdents,这个系统调用会把目录的目录项信息读取到一块内存里,之后程序可以解析这块内存里的数据来获得目录项的一些信息,这些信息一般包括了文件名,文件的类型,文件是否是目录等信息.
老代码在读取完这些信息后会利用文件名再次调用lstat,这个也是系统调用,可以获取更完整的文件信息,包括了文件的拥有者,文件的大小,文件的修改日期等.
老的代码有啥问题呢?大的问题不存在,接口也算易用,但有些小瑕疵:
os.FileInfo
返回的信息过多了。这些用不着的信息会浪费不少内存,获取这些信息也需要额外花时间——lstat需要去进行磁盘io才能得到这些信息,而目录里的文件不像目录项信息那样紧密的存储在一起,它们是分散的,所以一一读取它们的元信息带来的负担会很大。优化的代码其实只改了一行,是f.readdir(n, readdirDirEntry),第二个参数变了。新代码会走上面注释掉的那段逻辑:
// rec := buf[:reclen] 防止你忘了rec是哪来的
de, err := newUnixDirent(f.name, string(name), direntType(rec))
if IsNotExist(err) {
// File disappeared between readdir and stat.
// Treat as if it didn't exist.
continue
}
if err != nil {
return nil, dirents, nil, err
}
dirents = append(dirents, de)
取代lstat的是函数newUnixDirent,这个函数可以不依赖额外的系统调用获取文件的一部分元数据:
type unixDirent struct {
parent string
name string
typ FileMode
info FileInfo
}
func newUnixDirent(parent, name string, typ FileMode) (DirEntry, error) {
ude := &unixDirent{
parent: parent,
name: name,
typ: typ,
}
// 检测文件类型信息是否有效
if typ != ^FileMode(0) && !testingForceReadDirLstat {
return ude, nil
}
info, err := lstat(parent + "/" + name)
if err != nil {
return nil, err
}
ude.typ = info.Mode().Type()
ude.info = info
return ude, nil
}
文件名和类型都是在解析目录项时就得到的,因此直接设置就行。不过不是每个文件系统都支持在目录项数据里存储文件类型,所以代码里做了回退,一旦发现文件类型是无效数据就会使用lstat重新获取信息.
如果只使用文件名和文件的类型这两个信息,那么整个遍历的逻辑流程到这就结束了,文件系统提供支持的情况下不需要调用lstat。所以整个遍历只需要两次系统调用。这就是为什么优化方案会快接近五倍的原因.
对于要使用其他信息比如文件大小的用户,优化方案实际上也有好处,因为现在lstat是延迟且按需调用的:
func (d *unixDirent) Info() (FileInfo, error) {
if d.info != nil {
return d.info, nil
}
// 只会调用一次
return lstat(d.parent + "/" + d.name)
}
这样也能尽量减少不必要的系统调用.
所以整体优化的原理是:尽量充分利用文件系统本身提供的信息+减少系统调用。要遍历的目录越大优化的效果也越明显.
上面也说了,能做到优化需要文件系统把文件类型信息存储在目录的目录项数据里。这个需要文件系统的支持.
如果文件系统不支持的话最后还是需要依赖lstat去读取具体文件的元数据.
不同文件系统的信息实在太分散,还有不少过时的,所以我花了几天看代码+查文档做了下整理:
mkfs.xfs -f -n ftype=1
的选项才行xxx_readdir
这个函数附近。这么一看的话基本上主流的常见的文件系统都支持这种优化.
这也是为什么go1.16会引入这个优化,不仅支持广泛而且提升很大,免费的加速谁不爱呢.
看到这里,你应该发现这个优化其实是系统层面的,golang只不过是适配了一下而已.
确实是这样的,所以这个优化不光golang能吃到,c/c++/python都行.
先说说c里怎么利用:直接用系统提供的readdir函数就行,这个函数会调用getdents,然后就能自然吃到优化了。注意事项和go的一样,需要检测文件系统是否支持设置d_type.
c++:和c一样,另外libstdc++的filesystem就是拿readdir实现的,所以用filesystem标准库也能获得优化:
// https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/src/filesystem/dir-common.h#L270
inline file_type
get_file_type(const std::filesystem::__gnu_posix::dirent& d [[gnu::unused]])
{
#ifdef _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE
switch (d.d_type)
{
case DT_BLK:
return file_type::block;
case DT_CHR:
return file_type::character;
case DT_DIR:
return file_type::directory;
case DT_FIFO:
return file_type::fifo;
case DT_LNK:
return file_type::symlink;
case DT_REG:
return file_type::regular;
case DT_SOCK:
return file_type::socket;
case DT_UNKNOWN:
return file_type::unknown;
default:
return file_type::none;
}
#else
return file_type::none;
#endif
}
// 如果操作系统以及文件系统不支持,则回退到lstat
// https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/bits/fs_dir.h#L342
file_type
_M_file_type() const
{
if (_M_type != file_type::none && _M_type != file_type::symlink)
return _M_type;
return status().type();
}
唯一的区别在于如果目标文件是软连接,也会调用stat.
python:使用os.scandir可以获得优化,底层和c一样使用readdir:https://github.com/python/cpython/blob/main/Modules/posixmodule.c#L16211,实现方法甚至类名都和golang很像,代码就不贴了.
go虽然性能上一直被诟病,但在系统编程上倒是不含糊,基本常见的优化都有做,可以经常关注下新版本的release notes去看看go在这方面做的努力.
看着简单的优化,背后的可行性验证确实很复杂的,尤其是不同文件系统在怎么存储额外的元数据上很不相同,光是看代码就花了不少时间.
前面提到的ntfs在优化效果上会打点折扣,所以我特意拿Windows设备测试了下,测试条件不变:
可以看到几乎没什么区别。如果不是看了linux的ntfs驱动,我是不知道会产生这样的结果的。所以这个优化Windows上效果不理想,但在Linux和MacOS上是适用的.
大胆假设,小心求证,系统编程和性能优化的乐趣也正在于此.
exfat的fuse驱动填充d_type的逻辑:https://github.com/relan/exfat/blob/master/libexfat/utils.c#L28 。
Linux的ntfs驱动需要获取文件的inode才能得到正确的file type:https://github.com/torvalds/linux/blob/master/fs/ntfs3/dir.c#L337 。
最后此篇关于golang对遍历目录操作的优化的文章就讲到这里了,如果你想了解更多关于golang对遍历目录操作的优化的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我是一名优秀的程序员,十分优秀!