posted by wap, platform: Samsung

引用:

原帖由 @备常炭  于 2016-11-12 21:55 发表
实际上我公司的开发机是4T硬盘现在有650w文件，因为确实代码很多而且svn本地缓存就不说了

我认为py是搞不定的，实际上用c++不来点狠的方法32位程序也不太容易，无论是内存占用还是速度，要是扫一遍要几天那毫无价值

算了下。md5 hash 是128bit 长度。
假如1000w个文件内存占用 128 * 1000w = 160MB。
计算时间 貌似md5 是O(n) 复杂度？(n 为文件大小）
loop一遍file也是o(n)？
对比hash用hash map。 复杂度还是o(n).


这算法看起来瓶颈在md5 上。而不是内存上。（当然文件是肯定不能放到内存里。）。

可以考虑可以写一个类似md5的算法。大文件可以考虑不读取全部文件，读一部分chunk来生成hash。。



我的结论是我不认为py干不了。这就是个很简单的程序。。运行速度瓶颈更主要在于硬盘速度。而不是语言上。。。

posted by wap, platform: Samsung

引用:

原帖由 @solbadguy  于 2016-11-12 22:14 发表
我觉得摄影爱好者或者图片多的人都需要吧。有时候编辑过图片大小，或者调整过尺寸，又另存一张。这样一张图片就要有很多个版本，但是真正需要保存的一般都是原始图片。我现在只能用超大缩略图来筛选，但是超大缩略图有时还是分不清细微区别，但是一张张用看图软件打开筛选会死人的……

这个想法有意思啊。

posted by wap, platform: Samsung

引用:

原帖由 @备常炭  于 2016-11-13 13:19 发表
too young……

就一个文件来说，MD5才16个byte，那么消重和删除还得有文件的路径吧，你存吗？
就算存NTFS FRN这还是要多8个字节，这就240MB了，存全路径直接血崩。当然不用存全路径，内存里放个目录树就行了，每个文件指向自己的parent dir，这个指针4个字节，又多了40M

当然这都是只算数据本身，没有算容器的内存消耗，我只想说无论是vector还是map还是hashmap在这个数量级上都是血崩的，特别是new（malloc）本身的内存消耗。
不信你new 1000w个 16字节的结构体看看用了多少内存。

前段时间蛋疼恰好撸了这么一个玩意，直接上C++不用奇技淫巧，600w文件用大于1G内存。当然后来我用奇技淫巧优化后好看太多就不说了。

实在怕内存不够弄个no sql不就okay了。
还是不能理解Python为啥做不了。
这东西瓶颈在磁盘速度。