发现文本到长整数 ()和文本到整数 ()有趣的问题

呵呵仙8

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

苹果2014

文本到长整数 ()比文本到整数 ()执行效率还要高,那以后直接用文本到长整数 ()不就是快速了吗

呵呵仙8

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

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

Xelloss0618

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

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

呵呵仙8

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

我当初也认为是被编译优化了!





核心库命令,编译为发布版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 ())
}

呵呵仙8

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

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

Xelloss0618

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

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

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

yb1984724

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

numbersir

这么细节的地方都被你发现了，牛逼

呵呵仙8

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

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