为什么这个C风格的代码比这个obj-C风格的代码慢10倍?

时间:2009-09-09 03:07:33

标签: iphone c objective-c cocoa-touch

// obj C版本,有一些 - 在18,000次迭代中不到一秒

for (NSString* coordStr in splitPoints) {

  char *buf = [coordStr UTF8String];
  sscanf(buf, "%f,%f,", &routePoints[i].latitude, &routePoints[i].longitude);

  i++;

}

// C版 - 在18,000次迭代中超过13秒

for (i = 0; buf != NULL; buf = strchr(buf,'['), ++i) {

  buf += sizeof(char);
  sscanf(buf, "%f,%f,", &routePoints[i].latitude, &routePoints[i].longitude);

}

作为一个推论问题,有没有办法让这个循环更快?

另请参阅此问题:Another Speed Boost Possible?

4 个答案:

答案 0 :(得分:10)

测量,测量,测量。

使用仪器中的采样器仪器测量代码。

话虽如此,与Objective-C代码相比,C代码显然效率低下。

即,快速枚举 - for(x in y)语法 - 非常快,更重要的是,它意味着splitPoints是一个数组或集合,其中包含已被解析为的一堆数据个别对象。

第二个循环中的strchr()调用意味着您正在动态解析内容。就其本身而言,strchr()是一个循环操作,会消耗时间,因此目标字符出现之间的字符数会增加。

但这是所有猜想。与所有优化一样,推测是无用的,使用提供的[相当棒的]工具集来收集具体数据是确定的唯一方法。

一旦测量完毕,就可以加快速度。

答案 1 :(得分:3)

与性能无关,您的C代码中存在错误。 buf += sizeof(char)应该只是buf++。指针算术始终以类型的大小为单位移动。在这种情况下它工作得很好,因为sizeof(char)是1。

答案 2 :(得分:1)

Obj C代码看起来已预先计算了一些分裂点,而C代码在每次迭代中都会搜索它们。简单回答?如果N是buf的长度而M是分割点的数量,则看起来您的两个片段具有O(M)与O(N * M)的复杂性;哪一个慢?

编辑:我真的很惊讶,有些人会认为C代码在公理上比任何其他解决方案都要快。

答案 3 :(得分:0)

矢量化可用于加速C代码。

示例:

Even faster UTF-8 character counting

(但也许只是试图在循环条件中避免函数调用strchr()。)