为什么给文件进行排序时,以日期作为排序方式的排序速度要慢于以名称或大小为排序方式?
文件夹内文件数量越多差距越明显。原理是什么?
怀疑有一个因素是文件系统,filesystem,不同的文件系统对获取metadata的方式不同,同一个命令在不同文件系统下查找的表现也不同。
有现成的英文答案:https://jakubmarian.com/windows-8-10-sort-by-date-slow-solution/
简而言之,就是这个“日期”不是文件在你硬盘上被创建或修改的日期,而是图片/视频被创建/捕捉的日期,所以文件管理器要打开每一个图片/视频文件,读取这个属性,然后排序,在机械硬盘上对大量文件进行这一读取操作当然就会很慢了
解决方法是在文件管理器中单击右键,点“选择列”,然后去掉“日期”,选择“修改日期”,按修改日期排序就很快了
简而言之,就是这个“日期”不是文件在你硬盘上被创建或修改的日期,而是图片/视频被创建/捕捉的日期,所以文件管理器要打开每一个图片/视频文件,读取这个属性,然后排序,在机械硬盘上对大量文件进行这一读取操作当然就会很慢了
解决方法是在文件管理器中单击右键,点“选择列”,然后去掉“日期”,选择“修改日期”,按修改日期排序就很快了
我觉得名称排序好理解,默认排序基本上是名称。像是Windows这种文件名就是文件路径里名称的这种就明显了,但是Google Drive里文件显示名不是文件名,感受就不一样了
不负责任瞎猜 这个事可能跟索引有关系
字数不够怎么办?字数不够怎么办?字数不够怎么办?
字数不够怎么办?字数不够怎么办?字数不够怎么办?
我怀疑是文件管理器的屎山。
就比如说我移动nodejs的文件夹,几万个文件。用文件管理器移动就一定要扫描一遍,直接点击取消也能移动。但是用命令就可以飞速移动。
就比如说我移动nodejs的文件夹,几万个文件。用文件管理器移动就一定要扫描一遍,直接点击取消也能移动。但是用命令就可以飞速移动。
han_chinese
灰名单
理論上是檔名排序速度最快。
讀取每個檔案的属性都需要多一次讀取動作。
讀取每個檔案的属性都需要多一次讀取動作。
_ _ 理論上文件名 Hash 后, 和尺寸、日期排序都是一個量級應能做到 O(n log n), 你的情況是應用或平臺導致的. 若是自己實現代碼執行效率和預期相差太大看下獲取 API 是否選了個低效的.
没有过这种感觉。你是在什么操作系统下比较的这几种对文件排序?至少在MS Windows 下和Linux及Unix 下似乎对文件排序都是类似速度,按道理也应该速度类似,因为都是以文件名的某一属性作排序,各属性应该相互间无难度之分
@han_chinese 名称排序是比较字符串, 其它排序是比较一个整数
楼主你怎么不去先逆编译一下你的「排序功能实现」看看后再说?
日期只是一个INT,没理由排序最慢。你写一个脚本证明一下吧。
我觉得这个结论可能只是你的感觉,要试的话用几万个文件配合机械硬盘用几个排序方式掐表算一下吧,但感觉变量不好控制啊