'发现'优化

'find ./ -name *.jpg'

我想优化上面的语句的'发现'命令。'发现'优化

在find实现中处理'-name'谓词的方法。

static boolean 

pred__name __common (const char *pathname, const char *str, int flags) 

{ 

    boolean b; 

    char *base = base_name (pathname); 

    strip__trailing __slashes(base); 

    b = fnmatch (str, base, flags) == 0; 

    free (base); 

    return b; 

}

因为我寻找文件扩展名，并希望避免正则表达式基于字符串匹配，我 '替代B =的fnmatch（STR，基础上，标志）== 0;'与以下陈述

int strLen = strlen(base); 

b = FNM_NOMATCH; 

if (strLen>=4 && (str[3] == base[strLen]) && 
    (str[2] == base[strLen -1]) && (str[1] == 
    base[strLen-2]) && (str[0] == base[strLen-3])) 

{ 

b = 0; 

}

之后，我期望一些性能增益，但我没有看到上述变化后的任何种类的性能增益。

是我在做一些事情错了吗？
有没有更好的方法来优化'查找'以仅搜索文件扩展名？

来源

2009-12-16 Girish Kolari

分析后我在fnmatch上有一些更好的数字 - CPU使用率，fnmatch这个活动占用了将近16％的CPU。我认为，我不能减少运行查找所需的总时间（正如Thomas告诉它的是更多的磁盘活动），但应该可以通过一些更多优化来降低查找的CPU使用率。 – 2009-12-17 06:19:11

我怀疑正则表达式匹配是瓶颈。由于find遍历文件系统，开销可能是磁盘搜索时间，并且在内存文件系统的情况下，系统调用和结果上下文切换。

来源

2009-12-16 09:47:09 Thomas

如果开销只在磁盘寻道时间内，那么CPU使用率不应该是30％。查找中仅有2个主要部分 1.文件系统迭代（低CPU操作） 2.解析文件（高CPU操作） – 2009-12-16 10:08:43

@kolari：您应该执行一些分析并找出实际花费的时间。只是优化程序的一个随机部分将无济于事。 – 2009-12-16 12:14:20

+1表示瓶颈不在模式匹配中。另外，-name开关甚至不会执行完整的正则表达式，它只是执行更简单的典型shell扩展。 – netjeff 2009-12-16 16:58:35

回答

相关问题