0

根据关于 getcwd() 的 GNU Lib C 文档...

此函数的 GNU C 库版本还允许您为缓冲区参数指定空指针。然后 getcwd 自动分配一个缓冲区，与 malloc 一样（请参阅无约束分配）。如果大小大于零，那么缓冲区就是那么大；否则，缓冲区将与保存结果所需的一样大。

我现在提请您注意使用 GNU 文档中描述的标准 getcwd() 的实现：

char* gnu_getcwd ()
{
   size_t size = 100;
   while (1)
   {
      char *buffer = (char *) xmalloc (size);
      if (getcwd (buffer, size) == buffer)
        return buffer;
      free (buffer);
      if (errno != ERANGE)
        return 0;
      size *= 2;
   }
}

这对于可移植性和稳定性来说似乎很好，但它也看起来像是对所有分配和释放内存的笨拙妥协。鉴于可能会频繁调用该函数，这是否可能是性能问题？

*说“profile it”很容易，但这并不能说明所有可能的系统；现在或未来。

4

3 回答 3

3

初始大小为 100，包含 99 个字符的路径，比典型系统上存在的大多数路径都长。这意味着一般没有“分配和释放内存”，浪费的字节不超过 98 个。

每次尝试加倍的启发式方法意味着最多会发生对数个虚假分配。在许多系统上，路径的最大长度是有限的，这意味着对引起的重新分配的数量有一个有限的限制。

只要用作getcwd黑匣子，这几乎是最好的。

于 2014-07-25T13:37:12.053 回答
1

这不是性能问题，因为它是getcwd功能。如果该功能在您的关键路径中，那么您做错了。

开个玩笑，没有可以删除的代码。您可以通过分析改进这一点的唯一方法是调整幻数“100”（这是速度/空间的权衡）。即使那样，您也只会针对您的文件系统对其进行优化。

您可能还考虑将 free/malloc 替换为realloc，但这会导致不必要的内存复制，并且错误检查甚至不会减少代码。

于 2014-07-25T13:42:31.933 回答
0

感谢大家的意见和建议。我最近总结了从一开始就应该显而易见的事情：根据目标平台定义值（在本例中为“100”）和要使用的增量公式（在本例中为 x2）。这可以解释所有系统，尤其是在使用附加标志的情况下。

于 2014-07-26T21:49:24.183 回答