递归火山软件开发平台

标题: 删帖 [打印本页]

作者: shuimiao 时间: 2021-5-19 19:56
标题: 删帖
本帖最后由 shuimiao 于 2021-8-22 11:41 编辑

删帖

作者: shuimiao 时间: 2021-5-19 20:07
本帖最后由 shuimiao 于 2021-5-20 15:06 编辑

火山封装的数值型都是有符号的，无符号的没有封装，单精度小数没有。。变量参考和返回参考（不是通过参数的形式而是直接返回）也没有。还有c++的很多优秀指令如 new delete 都没有搞进去。吴总能不能把C++精粹吸收进来，高级用户需要嘛，新手不去碰又不会影响 @飞扬工作室 @创世魂

作者: 609177738 时间: 2021-5-20 07:24
直接嵌入方法""
@ (int)((byte*)@<字节集>.GetPtr())[@<位置>]
就行了哪那么复杂的东西

作者: shuimiao 时间: 2021-5-20 07:44

609177738 发表于 2021-5-20 07:24
直接嵌入方法""
@ (int)((byte*)@.GetPtr())[@]
就行了哪那么复杂的东西

也可以，不过直接对字节集类内部的指针变量操作，效率应该比返回指针再操作好一点吧，毕竟多了一个返回开销。我的写法是照搬字节集类内部改动的

作者: shuimiao 时间: 2021-5-20 08:22
本帖最后由 shuimiao 于 2021-5-20 08:24 编辑

609177738 发表于 2021-5-20 07:24
直接嵌入方法""
@ (int)((byte*)@.GetPtr())[@]
就行了哪那么复杂的东西

实测两千万字节数据，直接操作指针变量m_pData，耗时62毫秒，操作返回的指针，耗时250毫秒，官方方法耗时890毫秒。
指针返回再操作，多了个返回开销，速度就慢一点，官方方法有索引判断效率最慢

作者: 大强 时间: 2021-5-20 08:45
学习……

作者: 67564226 时间: 2021-5-20 11:19

作者: zqiz 时间: 2021-5-20 13:33
取字节集字节的极速方法，比官方方法快14倍

作者: oka32 时间: 2021-5-20 14:10
与/回复主题关闭
RE: 【开源】取字节集字节的极速方法，比官方方法快14倍 [修改]

作者: lijianye 时间: 2021-5-20 17:22
支持，有空试试

作者: 灿编程 时间: 2021-5-20 18:06

支持
支持
支持

作者: cxz7411 时间: 2021-5-21 09:59
看看怎么样

作者: ren178183 时间: 2021-5-21 10:01
不求最快但求最稳

作者: shuimiao 时间: 2021-5-21 10:56

ren178183 发表于 2021-5-21 10:01
不求最快但求最稳

这个就稳啊，不会不稳定的，相当于易语言字节集[字节索引]的方式调用，字节索引要自己确保不出错就行。

作者: 米粒 时间: 2021-5-21 17:18
好，学习了

作者: huniu9981 时间: 2021-5-21 18:28
牛XX

作者: TANE 时间: 2021-5-21 19:15
学习……

作者: hmyroot 时间: 2021-5-21 20:50
大神太牛了

作者: 4899 时间: 2021-5-22 09:09
学习学习

作者: jstion 时间: 2021-5-22 12:57
wrrrrrrrrrrrr

作者: 创世魂 时间: 2021-5-22 17:53

shuimiao 发表于 2021-5-20 08:22
实测两千万字节数据，直接操作指针变量m_pData，耗时62毫秒，操作返回的指针，耗时250毫秒，官方方法耗时8 ...

测试要编译发布版测试。。调试版测试不准。

作者: wuyamingg 时间: 2021-5-22 19:03

:):):):):):):):):):):):)

作者: shuimiao 时间: 2021-5-22 19:22

创世魂发表于 2021-5-22 17:53
测试要编译发布版测试。。调试版测试不准。

调试肯定慢过发布，但是如果调试下能提高速度，发布自然也更快。这点我在其他功能上对比过了

作者: 创世魂 时间: 2021-5-23 09:23
本帖最后由创世魂于 2021-5-23 09:29 编辑

好奇你是咋测试的。。。我直接找了一个20m的文件。。然后循环取字节集字节。。耗时0。。编译的64位发布版。

作者: 创世魂 时间: 2021-5-23 09:24
本帖最后由创世魂于 2021-5-23 09:30 编辑

shuimiao 发表于 2021-5-22 19:22
调试肯定慢过发布，但是如果调试下能提高速度，发布自然也更快。这点我在其他功能上对比过了 ...

你是怎么测试火山自带的。。。。实测，很快啊，飞快的，20兆的文件直接。。0秒。你上传个火山自带的测试例程。。我看看你是怎么测试的。。

作者: 创世魂 时间: 2021-5-23 09:26
本帖最后由创世魂于 2021-5-23 09:36 编辑

shuimiao 发表于 2021-5-22 19:22
调试肯定慢过发布，但是如果调试下能提高速度，发布自然也更快。这点我在其他功能上对比过了 ...

调试是不可能快的了。。调试要监控很多数据信息。。快是不可能快的。。而且火山的调试还加了内存监控之类的，这些东西易语言都没有【所以易语言调试更快】，如果后期调试器出来的话，可能会更慢一些，因为要监控的东西更多。

所以用调试版来对比测速结果。。明显不科学。。因为发布软件不可能去发调试版程序出去。。

测了一个20m的文件，0毫秒循环结束。找了一个40m的文件，也是0毫秒循环结束。。速度快的看不见。。

发布版快就行，调试版快不快没意义。。

作者: shuimiao 时间: 2021-5-23 09:37
本帖最后由 shuimiao 于 2021-5-23 09:39 编辑

创世魂发表于 2021-5-23 09:23
好奇你是咋测试的。。。我直接找了一个20m的文件。。然后循环取字节集字节。。耗时0。。编译的64位发布版。 ...

你看我上传的源码例子，是逐个读取全部字节的。里面假定19MB，在调试环境中可以对比，我的方法62毫秒，官方890毫秒，这都是在1秒内，所以你编译后肯定看不到差距了。编译后要看差距，你得把19MB变成190MB或更多，才能对比。

作者: 创世魂 时间: 2021-5-23 09:44

shuimiao 发表于 2021-5-23 09:37
你看我上传的源码例子，是逐个读取全部字节的。里面假定19MB，在调试环境中可以对比，我的方法62毫秒，官 ...

我找了一个300m的文件，还是0毫秒。

作者: shuimiao 时间: 2021-5-23 09:51

创世魂发表于 2021-5-23 09:44
我找了一个300m的文件，还是0毫秒。

300M逐个字节取出吗？

作者: 创世魂 时间: 2021-5-23 09:59
1910065408 字节。。大概1.7g了。还是0毫秒，我都开始怀疑人生了。。

作者: 创世魂 时间: 2021-5-23 10:46

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

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

作者: 创世魂 时间: 2021-5-23 10:53

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

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

作者: 网络注册会员 时间: 2021-5-23 11:31
原来是这样

作者: shuimiao 时间: 2021-5-23 19:15

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

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

作者: 呵呵仙8 时间: 2021-5-23 19:28
少了等于号。所以才快吧？

作者: weilai 时间: 2021-5-23 19:41
我怀疑是不是单纯的取字节集而不进行其他有实际意义的操作，所以被编译器认为是没有实际意义的代码被优化掉了

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

作者: shuimiao 时间: 2021-5-23 19:46

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

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

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

作者: shuimiao 时间: 2021-5-23 20:47

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

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

作者: 苹果2014 时间: 2021-5-23 21:01
学习学习

作者: lichenxui 时间: 2021-5-23 23:03
收下学习

作者: 共享冷却 时间: 2021-5-24 10:11
楼主辛苦了，谢谢楼主，感谢楼主分享，楼主好人一生平安！！！

作者: 创世魂 时间: 2021-5-24 17:20

shuimiao 发表于 2021-5-23 19:15
我也是服了。测试了确实如此，太疯狂了。。

所以你这个测试没意义。发布版快就行。。我找大佬问了。。

这些数据都是在内存里面操作的。里面的速度快的你没法想想的速度。。

作者: 创世魂 时间: 2021-5-24 17:21

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

编译发布版，火山测试都是0毫秒执行完毕。。调试版测试意义不大。。最多的就是增加以下调试速度。

作者: 创世魂 时间: 2021-5-24 17:23
你把帖子编辑一下吧，写上比火山调试快那么多。。。这样容易误导人的。。

作者: shuimiao 时间: 2021-5-24 19:01

创世魂发表于 2021-5-24 17:23
你把帖子编辑一下吧，写上比火山调试快那么多。。。这样容易误导人的。。 ...

改了哈哈

作者: 龙纹 时间: 2021-5-25 10:53

创世魂发表于 2021-5-23 09:59
1910065408 字节。。大概1.7g了。还是0毫秒，我都开始怀疑人生了。。

(, 下载次数: 62)
因为没使用被编译器优化了，加了赋值就不一样了。虽然这是测试代码，但是字节集这么写是有问题的，你截图里的这个取字节集长度值应该是溢出很多次后的结果了...调试版的效率测试很多都是没有意义的，对比发布版是正确的，但你这个测试不够严谨，内存操作再快也是需要时间的。

作者: wrx198728 时间: 2021-5-26 19:46
RE: 【开源】取字节集字节的极速方法，调试版比官方方法快14倍 [修改]

作者: chenyingnan 时间: 2021-5-27 15:13
谢谢分享谢谢了

作者: ynxyzl 时间: 2021-5-28 00:31

取字节集字节的极速方法，比官方方法快14倍

作者: arvin 时间: 2021-8-11 08:25
Seeeeeeeee

作者: zj3751 时间: 2021-8-11 09:56
让江小白来看看帖子里藏了啥好东西~~~

作者: IvzCX 时间: 2021-8-11 10:06
编译出来没差别就行了，搞得那么花里胡哨干嘛，官方的用着调试虽慢，但是若后期官方有优化也能惠及，自己搞得后期自己再去优化吗，最最主要的是编译出来没差别。

欢迎光临递归火山软件开发平台 (https://bbs.voldp.com/)