关于c 实现希望提高效率的探讨

写了一个图片压缩的程序（yuv420 to jpeg）函数，该函数条用了ffmpeg的库。执行该函数压缩一帧数据的时间是140ms左右的时间，现在压缩3张，如果串行执行的话，需要420左右ms的时间，由于其他原因，现在希望压缩3张图片的时间限制在180ms以内。请问有什么解决方案？（排除代码优化的可能，还有该函数里没有数据等待，或者是阻塞之类的函数）

用INTEL的IPP库.性能应该会高一些.或者针对多处理器做并行计算.
不过,现在的计算器做视频编码都不止30FPS.你压个图片这么慢.是计算机太老还是图片太大了哦

压缩的图片挺大的，是500w高清的。。。
说是用多线程并发，同时压缩3张图片。但是我觉得多线程的并发解决不了这种问题吧，我中间没有阻塞或者等待之类 函数啊。。。（该程序是运行在linux下的）

redleaves 说的多处理器+多线程能搞定这个工作，但是我条件有限哦，是不是只能按zhao4zhong1哥们说的是物理条件限制了哦

大家帮我说下，在一台计算机上能不能用的3个并行线程同时执行可以缩短时间吗？

怎么实现的不说，优化代码不让，这还有啥好讨论的。买个多核的机器，或者多买几台机器，并发处理吧。

但是这个是这样到， 我们主要是架构问题，因为该程序串行到时候，双核到cpu，一个只用了30%左右，另一个用了55%左右，这样的话，说明我们到cpu还没有完全利用。所以应该有办法提高我们到运算速度？你说呢？请指教哦。。。

你的代码没有问题，只能是硬件有问题，什么地方有瓶颈，总线太慢？内存太慢？硬盘太慢？

总的来说还行的。只是我想啊，可不可以采用比如多线程之类到东西来让cpu不用休息？？？您说呢？

很好奇C标准哪里提到可以({XXX})，并且还能有值的。
甚至更好奇，C标准哪里提到这个值是放在EAX里的。

想法是好的，不过人家没像你那么做，肯定有一定的道理的！

而不是一个字节一个字节的去弄的，呵呵 我这样写只是着重和 inline的比较，实际上是一样的，

你说的对，不过我的目的并不是要和系统自带的去比较，系统是经过优化的，CPU的优化规则大概如下：对于n字节(n = 2,4,8...)的元素，它的首地址能被n整除才能获得最好的性能，在32为机器上大多采用4,
系统内部采用的是这中办法longword + magic_bits) ^ ~longword) & ~magic_bits) != 0 ，来检查一个机器字长的字节内部是不是有byte hole,也就是整个一个字节 ‘/0’来判断是否到达字符串末尾：
换汤不换药，最多算是改写。而且安全性、健全性还降低了！还不如引用系统自带的！
赞成上面这句！

嗯不错，把函数本身的空间 （函数名地址开始到 地址内容为 c3(ret指令)结束）拷贝的数组里，然后从数组首地址执行，呵呵。
statement是不能当expression的.如果你的编译器支持这样写,那编译器肯定不够严格.甚至产生的是错误的代码.
按C/C++的语法规则
C语言中也能用inline的
我还是用inline算了，这个东西用起来不方便，不安全

引入gcc 扩展inline特性后linux内核基本都不用这种写法了，因为致命的缺点就是没有类型检查
linux内核中我们可以看到好多.h文件中 有很多 static inline 定义的函数，它完全取代了上面的带有返回值的宏，当然后来这种写法在应用层基本见不到了，慢慢的被人遗忘

有兴趣的可以在深入一下这个机制，这是编译器的处理，可以看下编译器对此段代码对应的汇编，返回值都会放在eax里面这是肯定的，函数也是如此，这个宏其实就是inline，预处理进行宏替换后这个和inline几乎完全一样，大家可以手动试试

呵呵，gcc内部增加了C++的inline，这种写法在gcc下基本销声匿迹了，都用的是inline 函数。
不过，assert这个跟我这个没关系吧， assert可是没有返回值的。。。
因此 它并没有用({...})来返回整个语句的值，这个是和逗号表达式相当的语句块表达式
来源：英超直播