每个月有 50g 的 tif 要转 png，有没有效率高一些的办法

直觉是程序写的效率问题，再来就是并行处理。

刚测试了一下，用 imagemagick 的 conver

用 photoshop 生成了一个 600M 的 tiff 文件 test.tiff

> time convert test.tif test.png
convert test.tif test.png 18.92s user 1.19s system 99% cpu 20.123 total

20 秒-600M
50G 算下来也就是 1700 秒=0.47 小时

如果开并行，应该是接近线性的时间关系。

硬件平台： mid2014 MBP i7 CPU

....8 小时 知足吧兄弟...

要便宜的话弄几台 x5650 的洋垃圾，要处理的时候开机然后并行跑，价格便宜量又足。

@3dwelcome 出版行业一般都是存 tif ，因为 tif 对白底黑字，白色面积较大的情况压缩率高，同等大小更清晰，反过来要是黑底白字那文件就更大了，考虑浏览器不支持 所以要再转 png 保存

@cfans1993 公司有挺大的机房，这个用途估计不给批啊。。。

@ins 主要是这个活每周都要处理新的，这周数据有 25g ，想着每周都干就看看有没有优化的空间

@moult 考虑过这样处理，瓶颈确实在带宽

imagemagick

不知道用 ps 的批处理感觉是怎样的……

先找瓶颈么，找到了再对应优化

图喵 表示太恐怖了

学校有人用 sed | awk | > | cat 去转换 BIND zones ， 3 亿纪录花了一晚上

我看了看他的 bash script ，各种打开文件关闭文件管道 不慢才怪

同楼上 先找瓶颈

@xenme
@CupTools 好的 ，今天在用 freeimage 写的这份源码了，初步判断处理起来瓶颈应该在并行，谢谢各位

@nellace IO 也可能会是瓶颈

加入收藏

其实 c#写的也问题不大，只要正对某个“平台”选择特定的平台编译就好了。

然后看瓶颈，是 io 瓶颈，就改 ssd ，用 ssd 做转换任务中的临时盘，转换完成了，再搬会机械盘。
如果是内存，就加内存。是 cpu 就加 cpu 。

实在没有其他办法，你也只能考虑用 c 重写，或者楼上几位说的用 gpu 。

一般服务端优化的套路大致从这几个入手

@sgissb1 如果内存够，文件不是很重要的话可以全放内存里，然后转存硬盘。

这个场景蛮适合用七牛的，存储和转码基本是白菜价，和电费差不多了。。

又不用你盯着， 8 小时就 8 小时呗，睡一觉不就完成了