递归火山软件开发平台

标题: 发现文本到长整数 ()和文本到整数 ()有趣的问题 [打印本页]

作者: 呵呵仙8 时间: 2023-10-29 22:46
标题: 发现文本到长整数 ()和文本到整数 ()有趣的问题
(, 下载次数: 21)
大家有没发现,文本到长整数 ()比文本到整数 ()执行效率还要高!!
以计次循环 (100000000)为例.转化为整数花费时间2700毫秒左右!
而转化为长整数花费时间0毫秒!(编译为发布版速度)目测,最少3000倍效率!这个StrToN64函数是吴总自创的算法吗?_ttoi函数也是自创的吗?当初为何不用StrToN64函数的返回值强转为int返回为整数.文本到整数 ()不就速度飞起来了?省时省脑!如下图:
(, 下载次数: 23)

作者: Xelloss0618 时间: 2023-10-29 23:45
你的测试代码有问题吧，单单计次循环那么多次就不可能是 0 毫秒，C++ 的编译优化会将你的无效代码删除掉。
使用 #pragma optimize( "", off) 禁用编译优化后，实际性能差距应该是 5 倍左右。

_ttoi 是 C 的函数，速度已经算好了，C++11 的 std::stoi 更是慢得出奇。

长整数不能无脑强制转换成 32 位整数，因为转换的原则是直接砍掉后面 4 个字节。
比如长整数值 5000000000 (0x00F2052A01000000)，强转到整数后是 705032704 (0x00F2052A)。

作者: 山梦 时间: 2023-10-30 09:02
大佬厉害

作者: CPUCN 时间: 2023-10-30 09:07
这么细节的地方都被你发现了

作者: suyan 时间: 2023-10-30 09:14
占用时间应该是那个强转INT带来的

作者: kantal 时间: 2023-10-30 09:42
这么细节的地方都被你发现了

作者: IvzCX 时间: 2023-10-30 10:02
666

作者: Xelloss0618 时间: 2023-10-30 11:35
昨天发的回复还没放出来，这里简单给个结论，你的测试代码没考虑编译优化，实际性能差距是5倍左右

作者: suyan 时间: 2023-10-30 11:42
X大佬出结果就定案了，强转要占时间，不过相差几十倍，是不大可能

作者: 呵呵仙8 时间: 2023-10-30 12:19

suyan 发表于 2023-10-30 09:14
占用时间应该是那个强转INT带来的

会错意了.后图是个人建议"文本到整数()"源码变更为这样.速度才和"文本到长整数()"一样快!!

作者: numbersir 时间: 2023-10-30 13:22
这么细节的地方都被你发现了，牛逼

作者: yb1984724 时间: 2023-10-30 14:49

编译了看看C++代码是怎么写的?

作者: Xelloss0618 时间: 2023-10-30 15:35

呵呵仙8 发表于 2023-10-30 12:19
会错意了.后图是个人建议"文本到整数()"源码变更为这样.速度才和"文本到长整数()"一样快!! ...

直接强转是不准确的，你可以测试一下这个代码。
调试输出 (文本到长整数 ("5000000000"), 文本到整数 ("5000000000"), (整数)文本到长整数 ("5000000000"))

_ttoi 这个C函数比吴总的 StrToN64 只慢2到6倍左右。

作者: 呵呵仙8 时间: 2023-10-30 16:58

Xelloss0618 发表于 2023-10-30 15:35
直接强转是不准确的，你可以测试一下这个代码。
调试输出 (文本到长整数 ("5000000000"), 文本到整数 ("5 ...

我试过,如果文本是整数范围内的文本,不存在错误返回的!

作者: 呵呵仙8 时间: 2023-10-30 18:18

Xelloss0618 发表于 2023-10-30 11:35
昨天发的回复还没放出来，这里简单给个结论，你的测试代码没考虑编译优化，实际性能差距是5倍左右 ...

我当初也认为是被编译优化了!
(, 下载次数: 15)

(, 下载次数: 17)

核心库命令,编译为发布版EXE,整体过程用时为14359毫秒!
改核心库命令,编译为发布版EXE,整体过程用时为11625毫秒!
那么,14359毫秒-11625毫秒=2734毫秒.就是这个改过的代码速度!因为前面的代码没变.
所以,不存在什么编译优化之说.它就这样的3000倍或更高的转化效率!!

<火山程序类型 = "通常" 版本 = 1 />
如果 (来源对象 == 按钮1)
{
变量 JB_测速 <类型 = 类_测速>
变量 JB_文本型 <类型 = 文本型>
变量 JB_整数 <类型 = 整数>
变量 a <类型 = 整数>
JB_测速._测速开始 ()
计次循环 (100000000)
{
      a = a + 1
      如果真 (a == 2147483647)
      {
         a = 0

      }
      JB_文本型 = 到文本 (a)
      JB_整数 = _文本到整数 (JB_文本型)

}
调试输出 ("JB_整数:", JB_整数)
标签1.标题 = JB_测速._测速结束 () + ":" + 到文本 (JB_整数)
}

<火山程序类型 = "通常" 版本 = 1 />

方法 _文本到整数 <公开静态类型 = 整数注释 = "将所指定文本转换到整数并返回" 折叠 @嵌入式方法 = "">
参数所欲转换的文本 <类型 = 文本型>
{
@ (int)StrToN64 (@<所欲转换的文本>.GetText ())
}

作者: Xelloss0618 时间: 2023-10-30 20:44

呵呵仙8 发表于 2023-10-30 18:18
我当初也认为是被编译优化了!

谁教你这样测性能的……
应该是 (14359 - 11625) / 14359，快19%
排除多余的代码，只用文本到整数，关闭编译优化我测出来是快 5 倍左右，默认编译优化是快 2～3 倍。

作者: 呵呵仙8 时间: 2023-10-30 21:28

Xelloss0618 发表于 2023-10-30 20:44
谁教你这样测性能的……
应该是 (14359 - 11625) / 14359，快19%
排除多余的代码，只用文本到整数，关闭 ...

的确,好神奇,昨晚0毫秒.今晚要1秒完成转化

作者: 苹果2014 时间: 2023-11-1 17:08
文本到长整数 ()比文本到整数 ()执行效率还要高,那以后直接用文本到长整数 ()不就是快速了吗

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