删帖

创世魂

shuimiao 发表于 2021-5-23 09:51
300M逐个字节取出吗？

那肯定是啊。。。循环取的。和你的方法一样的。上面1.7g的数据。。都耗时0.我都怀疑人生了。。我怀疑我是不是写错了。

创世魂

shuimiao 发表于 2021-5-23 09:51
300M逐个字节取出吗？

我搞了一个700m的压缩包，依然0毫秒。。循环取出。。

网络注册会员

原来是这样

shuimiao

创世魂 发表于 2021-5-23 10:46
那肯定是啊。。。循环取的。和你的方法一样的。上面1.7g的数据。。都耗时0.我都怀疑人生了。。我怀疑我是 ...

我也是服了。测试了确实如此，太疯狂了。。

呵呵仙8

少了等于号。所以才快吧？

weilai

我怀疑是不是单纯的取字节集而不进行其他有实际意义的操作，所以被编译器认为是没有实际意义的代码被优化掉了

weilai

所以看起来是执行了几千万几亿次，其实被编译器优化后就是无用代码没执行，这是我的猜测

shuimiao

weilai 发表于 2021-5-23 19:43
所以看起来是执行了几千万几亿次，其实被编译器优化后就是无用代码没执行，这是我的猜测 ...

这样解释的的话倒是可能。如果是这样，那实际应用环境中，这个极速取字节集方法应该还是有较大优势的。等日后看看

fengshangren

这样直接取肯定最快了，但是火山的取字节集数据，是要兼容很多火山类型的，内部有很多判断。

shuimiao

fengshangren 发表于 2021-5-23 20:12
这样直接取肯定最快了，但是火山的取字节集数据，是要兼容很多火山类型的，内部有很多判断。 ...

所以现在弄这个不加判断的，直接取字节的，就像易语言的 字节集[索引]，而官方没有这种。