为什么'file.size'需要花费大量时间,以及如何减少时间？

Question

我正在制作一个应用程序来处理被拖动到应用程序的歌曲.当我使用它file.size来获取文件的大小时,需要大约1500毫秒(平均)来获得此值.有没有更快的方法？我理解为什么需要时间(和内存),但由于我是处理HTML5中的文件的新手,可能有一些我不知道哪些可以使这个过程更快.

文件系统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 GB的ram,win7 x64.我相信的规格实际上还算不错.因此,如果某些东西在我的机器上需要足够长的时间,我将把它视为禁忌.

这是我的应用程序中的主要错误修复的阻止程序.我真的很想包括这个很长一段时间的修复程序.我不能设置赏金(但)也许在设置赏金之前有最短的时间.

编辑

我做了一些测试,事实证明,它需要很长时间,因为chrome 计算 的大小而不是从一些元数据中读取它.这是测试结果.

文件越大,所需的时间越长,如果第二次调用则使用一些缓存并且不加载文件.所以现在..我怎么能减少这个时间？大小是我的应用程序中的一个重要信息,但可能不足以使用户的上传速度降低大约1.5秒的每个文件!我正计划导入库,当添加100首左右的歌曲时,这将有助于减少这段时间.这一次将成为应用响应时间的重大突破.

Answer 1

这是一个准教育的猜测:

查看HTML5 File接口的定义表明a File是a Blob,并且该size属性实际上是Blob接口的一部分.

由于a Blob是对原始数据块的抽象,因此访问该size属性实际上可能导致实现将整个文件加载到内存中.您可以编写一个实验来查看延迟是否随文件大小而变化,或者延迟是否仅在第一次读取size属性时发生.

编辑:

我觉得这种低效率是浏览器File界面实现的一个问题,但这里有两个解决方法,关于如何在将大文件加载到内存时避免延迟:

Web worker(MDN参考,WHATWG Webapps Standard)允许您将文件的缓慢加载基本上放入另一个线程中.我认为这是你最好的选择.

另一种方法是使用slice方法的的Blob接口加载了的一小部分File.如果实现slice仅加载文件的所需部分,则应该更快.您必须为每个文件加载多个切片,并且您需要通过关注Blob返回的大小来检测何时到达文件末尾slice.您将通过从规范中获取小于预期的blob来检测文件的结尾:

如果索引算法超出大小的边界,则切片方法必须钳制大小值.特别是,这意味着对于给定的切片调用:

如果start + length> size,则用户代理必须返回Blob对象,就像调用slice(start,size-start)一样.

如果start> size,则用户代理必须返回大小为0的Blob对象

不幸的是,规范还提到了当你在Blob缓冲区大小之外请求切片时抛出异常的可能性 - 在任何实现这种情况的实现上,你必须捕获异常以检测文件的结尾.