工具/软件:TI C/C++编译器
使用 TI v 16.9.6 LTS、mktime()函数需要17ms 的运行时间、从而缩短了我的应用程序的计时。 我在5年前使用 CCS 5.3附带的任何编译器运行了同一个应用程序、虽然我在5年前没有运行过该程序、但它并没有花费那么长的时间。 我只能说,以前的时间是按设计的,现在不是这样的,而犯罪者似乎是 mktime()。 可能影响这一点的任何编译器选项? 我在优化方面使用的编译器选项与5年前相同。 谢谢!
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:TI C/C++编译器
使用 TI v 16.9.6 LTS、mktime()函数需要17ms 的运行时间、从而缩短了我的应用程序的计时。 我在5年前使用 CCS 5.3附带的任何编译器运行了同一个应用程序、虽然我在5年前没有运行过该程序、但它并没有花费那么长的时间。 我只能说,以前的时间是按设计的,现在不是这样的,而犯罪者似乎是 mktime()。 可能影响这一点的任何编译器选项? 我在优化方面使用的编译器选项与5年前相同。 谢谢!
RTS 库的源代码(包括 mktime)是编译器安装的一部分。 您可以在类似...的目录位置找到它。
C:\ti\ccsv7\tools\compiler\ti-cgt-msp430_16.9.6.LTS \lib\src
查找以"mktime"开头的文件名。 我将大约5年前的某个版本中的 mktime 实现与16.9.6.LTS 版本中的实现进行了比较。 基于这一点、我看不到有任何理由期望有很大的差异。
在较旧的编译中、RTS 代码可能会从快速内部存储器执行、而在较新的编译中、RTS 代码可能会从慢速外部存储器执行吗?
谢谢、此致、
乔治
谢谢、George。
因此没有外部存储器;只需使用闪存和 RAM、我验证了 mktime 是否正在从闪存运行。
但我将 mktime 代码复制到本地存储库中、并进行必要的更改以使其正常工作、并确定在 mktime 中花费17ms 大部分时间的行如下所示:
tptr ->tm_wday =((eparch_WDAY + daycount)% 7)+ 7)% 7;
似乎是模数运算符需要很长时间、但计时很长、因此这不起作用。
我将对优化进行实验、看看这是否有用。
还有其他想法吗?
谢谢!
Lara