文件系统API也是如此.如果我通过它调用文件并调用file.size,则需要类似的时间.
PS我通过在我的代码中添加console.time()得到这个结论.
这里是代码(大大减少了)
fileSystem.root.getFile(id,{},function(fileEntry) {
fileEntry.file(function(audioTemp) {
console.time(1);
console.log(audioTemp.size);
console.timeEnd(1)
});
});
这是文件系统API示例.这(显然)需要一个名为id的文件才能工作.以下是D&D文件输入代码
function onChangeAddSongsInput() {
var files = document.getElementById('addSongsInput').files;
for(var i=0; i<files.length; i++) {
console.time(1);
console.log(files[i].size);
console.timeEnd(1)
}
}
编辑
我在AMD的核心两个二重奏,2.7 GHz,2 gig的ram,win7 x64,我相信的规范实际上是体面的.所以如果某些东西在我的机器上花费足够长的时间,我会把它作为一个不要去的东西.
这是我的应用程序中的主要错误修复的阻止程序.我真的很想运送这个很长时间的修复包括.我不能设置一个赏金(还),也许在设置赏金之前有一个最短的时间.
编辑
我做了一些测试,事实证明,它需要很长时间,因为chrome计算大小,而不是从一些元数据中读取它. Here是测试结果.
文件越大,需要的时间越长,如果第二次使用某些缓存,并且不加载文件.所以现在..我该如何减少这个时间？大小是我应用程序中的重要信息,但可能不够重要,可以将用户的每个文件上传速度降低约1.5秒！我正在计划进口图书馆,这真的有助于减少这个时候添加100首歌曲.这段时间将是应用程序响应时间的重大突破.
解决方法
看看the definition of the HTML5 File interface显示一个文件是一个Blob,并且size属性实际上是Blob interface的一部分.
由于Blob是原始数据块的抽象,因此访问size属性可能会导致实现将整个文件加载到内存中.您可以编写一个实验来查看延迟是否随文件大小而变化,或者延迟仅在第一次读取size属性时发生.
编辑：
我真的觉得这种低效率是浏览器实现File界面的一个问题,但是在将大型文件加载到内存中时,这里有两个解决方法：避免延迟;
Web工作人员(MDN reference,WHATWG Webapps Standard)将允许您将文件的缓慢载入本质上放在另一个线程中.我认为这是你最好的选择.
另一种方法是使用Blob接口的slice method加载文件的一小部分.如果切片的实现仅加载文件的所需部分,则应该更快.您必须为每个文件加载多个片段,并且您需要通过注意片段返回的大小来检测何时到达文件的末尾.您将通过返回一个比您预期的更小的blob来检测文件的结尾 – 从规范中：
The slice method MUST clamp on values of size if index arithmetic exceeds the bounds of size. In particular,this means that for a given slice call:
If start + length > size then a user agent MUST return a Blob object as if slice(start,size-start) was called.
If start > size then a user agent MUST return a Blob object of size 0
不幸的是,该规范还提到了在Blob缓冲区大小之外请求切片时抛出异常的可能性 – 在执行此操作的任何实现上,都必须捕获异常来检测文件的结尾.
