长时间计时不要用TimerDiff,应该用_Date_Time_GetTickCount
本帖最后由 unique009 于 2012-11-26 22:44 编辑前段时间我做了一个运算量很大的程序,运行一次几乎要占满CPU跑30分钟左右,之前一直用TimerDiff来计算每次的运行时间.有一次我在运行此程序的同时又开了另外好几个大程序,CPU双核都差不多占满了.大概一小时后那个程序才提示运算完成,但TimerDiff的结果仍然是30分钟左右,所以我当时很奇怪,又换成_Date_Time_GetTickCount跑了一遍,50多分钟,这差距也太大了,TimerDiff的结果居然比实际时间慢了40%,去官网也没找到相关解释.
我不知道TimerDiff内部是怎么实现的,但是看autoit帮助中TimerDiff的精度相当高(毫秒级,后面还有n个小数位),很可能是用的QueryPerformanceCounter函数吧,不过这个函数要用到QueryPerformanceFrequency的值,当CPU可以自动调频运行时,这个值好像不准吧
现在想起来这个问题,写出来讨论一下
刚想到还有一个asm指令rdtsc也是高精度的,但这个在双核机上应该也是不准的吧 回复 1# unique009
不知所云~~~ 本帖最后由 netegg 于 2012-11-26 13:34 编辑
按理说，timerdiff应该也是用的gettickcount或者timer api一类的，可能是核心编码中有什么改变吧，这个可能需要看autoit的源代码了
datetimer udf走的是api的路子，直接使用的是系统操作
估计不会用QueryPerformanceCounter这类高精度计时的 不过就我所知GetTickCount之类的,精度只能到毫秒,但是看timerdiff虽然也是毫秒精度,但是小数点后那么多位,估计是纳秒级的吧
现在回想起来,我用的timerdiff好像就从来没准过,如果不是用QueryPerformanceCounter,那就很可能是asm指令rdtsc,但是这个指令在CPU乱序执行时是不准的,超线程或多核下也是不准的 回复 3# netegg
我记得论坛是08年五一开的,你8号注册,我23号注册,但金钱上差距咋这么大啊 回复 5# unique009
贴数，时长，贡献 本帖最后由 netegg 于 2012-11-26 14:33 编辑
回复 4# unique009
到不了，timerdiff是秒级，毫秒精度都是约数
zwdelayexecution，是毫秒级，纳秒是约数 回复 4# unique009
后面的数根本没有意义的,比纳秒都小几亿倍~~
AU处理毫秒能准确些就满足了,别想微秒的事,特别是窗口消息相关的,接收个消息也需要1毫秒左右~~
太快了力不从心~ 本帖最后由 netegg 于 2012-11-26 15:49 编辑
回复 8# annybaby
不能这么说，这个可能和实际操作无关，但和运算机制的关系就大了
不太恰当的比方，字符串操作普通方式就可以完成为什么要用正则，尤其是一个特定字符串的时候 回复 9# netegg
是的,这个比方可能真的不太恰当~~
AU通过调用API来完成,但中间多了不少的其它判断等步骤,可能完成这些额外步骤所需要的时间,比自己要求的时间精度要大得多,所以结果就~~ 回复 10# annybaby
只是简单的无参数函数对调用产生的影响不大，一旦交给dll后，和auto的关系几乎就没有了 回复 11# netegg
嗯,简单的是,但好多都有参数吧,特别是一些还可能需要对如坐标等信息两转成结构之类的,然后还有一些判断等,效率上就慢多了~
当然,在UDF中自己处理一些数据,并用户更方便调用也可能正好是AU的魅力所在~~ 回复 12# annybaby
带参数的话意味着在进入dll前的处理过程，那是脚本自身处理的事，已经不再dll范围了
不信的话，你用二进制来写auto的文件，直接加载到内存运行，要快得多 回复 13# netegg
{:face (394):}
我说的明显就是脚本自身,而不是说DLL慢~~ 本帖最后由 netegg 于 2012-11-26 19:47 编辑
回复 14# annybaby
楼主发帖的主题可以引申到是使用脚本自身代码处理还是api处理的问题，是如何计时准确，不是如何处理数据快
你把赋值结构单提出来，我才会有上面一说