CrLf

至于15楼的代码，我不懂编程，但是从vbs和bat的差别中猜测编程的计算方法、赋值方式完全不同于bat，所以exe的计算速度远快于cmd，生命游戏就是一个例子，可以exe版和bat版生命游戏来对比出同尺寸图、同样代数的用时

CrLf

这个是我没考虑周全，我原以为读取变量会慢些，所以当时没细想。但是楼上既然知道启动耗时大于一次计算耗时，那为什么一次set中只计算一次呢？这样一来计算耗时之差会被set启动耗时淹没，自然不明显了。我用set /a 1*1,1*1,1*1,1*1....的办法就是为了让计算耗时所占比重最大化。

@echo off&setlocal enabledelayedexpansion
set n=1&set s=n*n
for /l %%a in (1 1 9) do set s=!s!,!s!
title %n%
echo %time%
for /l %%i in (1,1,10000) do (
     set /a %s%
)
echo %time%
pause
复制代码

结果n=1时耗时39秒，n=1234567890时耗时44秒，这又作何解释呢？

qzwqzw

不同情况下“算式的预处理耗时”之间和“计算耗时”之间的差异。
这一点用批处理似乎没办法验证吧？

我是否可以理解为
你已经取消了以前“计算耗时是存在的，并且相差极大”的论断？

正如你说
计算耗时与预处理耗时难以严格区分
但是你从我的批处理代码仍然没有看出什么吗？

是的
1*1和1234567*1234567必然会有预处理上的差异
我们所能做的只有尽量减少这部分差异
所有我使用了从内存变量中读取操作数的做法
那比从命令行读取操作数要快很多
相对而言耗时差异也会缩小

wayaoqiang

听说, 真理是掌握在少数人手里的, 我看正方人少, 就支持了下

CrLf

好吧，那我们来总结一下，暂时把一句set /a的耗时划分为六部分：
1、语块的预处理耗时
2、变量延迟耗时
3、set命令的启动耗时
4、算式的预处理耗时
5、读取变量耗时
6、计算耗时（实际操作的时候不知道是否和第四部分同时完成）
7、赋值耗时

在这几部分中，1、2、3部分的耗时浮动可以多次测试用平均值尽量排除，而第5、7部分在我的测试代码中不存在，也就是说，我们现在争论的焦点是不同情况下“算式的预处理耗时”之间和“计算耗时”之间的差异。
这一点用批处理似乎没办法验证吧？

qzwqzw

set本身也有启动耗时，并且应该远远大于计算耗时，所以需要以set /a n*n,n*n的形式来尽量缩小启动用时所占的百分比
我写了一段代码来证明，1*1与1234567890*1234567890耗时分别为13秒与17秒，证明计算耗时是存在的， ...
zm900612 发表于 2011-3-20 13:03

看不出你的这段代码与以前的有什么本质上的不同
启动耗时当然会有（我这里理解为将命令加载到内存并进行预处理的耗时）
而且也有可能确实大于计算耗时（我这里理解为命令在内存中参与运算和执行的耗时）
但你的代码如何能证明启动耗时与计算耗时相差极大？
你确认你的代码对于1*1和1234567890*1234567890
他们的启动耗时（具体的说就是对命令行的预处理）是一样的吗？
如果不是一样的
你又如何比较计算耗时的差别呢？

hanyeguxing

以楼主给出的这两对数字，以32位系统来说，速度是一样的

CrLf

set本身也有启动耗时，并且应该远远大于计算耗时，所以需要以set /a n*n,n*n的形式来尽量缩小启动用时所占的百分比
我写了一段代码来证明，1*1与1234567890*1234567890耗时分别为13秒与17秒，证明计算耗时是存在的，并且相差很大

@echo off&setlocal enabledelayedexpansion
set s=1234567890*1234567890
title %s%
for /l %%a in (1 1 9) do set s=!s!,!s!
echo %time%
for /l %%i in (1,1,20000) do (
     set /a %s%
)
echo %time%
pause
复制代码

CrLf

但是楼上似乎忽略了set命令本身也有启动耗时，一次计算耗时和一次启动耗时应该相差很大的，我写了以下代码验证，结果证明1*1与1234567890*1234567890的耗时分别为13秒与17秒

@echo off&setlocal enabledelayedexpansion
set s=1*1
title %s%
for /l %%a in (1 1 9) do set s=!s!,!s!
echo %time%
for /l %%i in (1,1,20000) do (
     set /a %s%
)
echo %time%
pause
复制代码

qzwqzw

嗯，预处理
终于有人想到了这个
嗯再贴一段ANSI C代码
把1234567*7654321换成1*1
即可进行比照测试
我使用WinTC2编译链接后
放在批处理中测试
两段程序的耗时均为59.06秒
时间性能差距小于10ms
这又说明什么问题呢？

#include "Stdio.h"

int main(void)
{
 long i,j,s;
 i=j=s=0;
 for (i=0;i<100000;i++)
   for (j=0;j<100000;j++)
     s=1234567*7654321;
}
复制代码

CrLf

不过仔细想想，也许正是因为语句的字符长度不同导致预处理时间相异，所以4楼代码才会有这么明显的差别。
仅仅个人猜测而已，未验证

CrLf

楼上考虑过for /l循环本身的用时吗？

qzwqzw

很可惜！
辩论没有向我想象的那个方向发展

好吧
既然选了正方
我就抛出一些正方的观点和证据

下面这段测试代码中
将set /a m=1换成set /a m=1234567
既可以进行对照测试
在我的环境下
总体运行时间在31~32秒之间
而两段程序的时间差小于1.7秒
也就是说两段程序的时间性能差距在%5之间
这个跟四楼的代码大于40%的差距相比
应该算不上明显的差距吧？

@echo off&setlocal enabledelayedexpansion
set /a m=1
echo %time%
for /l %%i in (1,1,1000) do (
	for /l %%j in (1,1,1000) do (
		set /a s=m*m
	)
)
echo %time%
echo %s%
pause
复制代码

CrLf

又做了几个测试：

1*1000000,1000000*1
没有大于0.3秒的差别，但是几次测试，后者始终稍快，说明计算前可能并未比较数字大小

而805306366*2却比127867*12596（乘积均为1610612732）
前者快了近两秒，说明确实与复杂度有关，看来有可能真的是用加法，不过究竟具体操作的时候倍增还是指数增长就不得而知了。

536870912*3,1073741823*3（两个大数分别为10000.....00和11111.....11，二进制位数相同）
没有大于0.3秒的差别，数次测试中，前者始终稍快，说明速度和二进制形态或者十进制字节数有关。

1073741824/2,2147483647/2（同上，只比前一个例子的数多一位二进制位数）
前者快了将近半秒，说明同样的字节（包括十进制和二进制）长度下，速度可能由这个数的二进制形态决定。

caruko

一般来说，电脑处理数值计算跟数值的字节长度有关系。

电脑的二进制加法器电路是通过“异或门”电路跟“与门”电路来计算结果的。
一般的高级语言在计算时都要指定数值精度，比如 8字节的int型数值是0-255。
电脑每次处理8字节int型数值计算时，都需要从最低位计算加到最高位。
所以字节数一样的数，计算时间一样，1+1 跟1+100是一样的。

在一般的程序语言中，“1234567”这个数比“1”明显字节长度更长，加法器需要花更多时间计算。
虽然不确定批处理转换后的数字是多少字节，因为字符跟数字没有分开，不知道如何转换的，或者存储结构是特殊设计的。
但3楼代码可以看出批处理在解释数字时，还是会自动匹配合适字节的数。