shuimiao 发表于 2021-5-23 09:51
300M逐个字节取出吗？
那肯定是啊。。。循环取的。和你的方法一样的。上面1.7g的数据。。都耗时0.我都怀疑人生了。。我怀疑我是不是写错了。
shuimiao 发表于 2021-5-23 09:51
300M逐个字节取出吗？
我搞了一个700m的压缩包，依然0毫秒。。循环取出。。
原来是这样
创世魂 发表于 2021-5-23 10:46
那肯定是啊。。。循环取的。和你的方法一样的。上面1.7g的数据。。都耗时0.我都怀疑人生了。。我怀疑我是 ...
我也是服了。测试了确实如此，太疯狂了。。
我怀疑是不是单纯的取字节集而不进行其他有实际意义的操作，所以被编译器认为是没有实际意义的代码被优化掉了
所以看起来是执行了几千万几亿次，其实被编译器优化后就是无用代码没执行，这是我的猜测
weilai 发表于 2021-5-23 19:43
所以看起来是执行了几千万几亿次，其实被编译器优化后就是无用代码没执行，这是我的猜测 ...
这样解释的的话倒是可能。如果是这样，那实际应用环境中，这个极速取字节集方法应该还是有较大优势的。等日后看看
这样直接取肯定最快了，但是火山的取字节集数据，是要兼容很多火山类型的，内部有很多判断。
fengshangren 发表于 2021-5-23 20:12
这样直接取肯定最快了，但是火山的取字节集数据，是要兼容很多火山类型的，内部有很多判断。 ...
所以现在弄这个不加判断的，直接取字节的，就像易语言的 字节集[索引]，而官方没有这种。