我写了一个非常粗糙的爬山/贪婪算法来解决旅行商问题。目的是将其作为基准，不断改进运行时间并同时优化解决方案。
编辑：根据Stefan Pochmann的建议，这似乎与硬件而非程序有关。在i7-4790处理器上，在开始爬坡循环之前立即执行Function Register-Watcher {
param ($folder)
$filter = "*.*" #all files
$watcher = New-Object IO.FileSystemWatcher $folder, $filter -Property @{
IncludeSubdirectories = $false
EnableRaisingEvents = $true
}
$changeAction = [scriptblock]::Create('
# This is the code which will be executed every time a file change is detected
$path = $Event.SourceEventArgs.FullPath
$name = $Event.SourceEventArgs.Name
$changeType = $Event.SourceEventArgs.ChangeType
$timeStamp = $Event.TimeGenerated
Write-Host "The file $name was $changeType at $timeStamp"
$input_path = $name
$output_file = 'C:\site-download\output.txt'
$regex = '(?<month>VPIP<\/span><span class=""right"">\d{2}.\d{1})'
$regex2 = '(?<month>Winrate<\/span><span class=""right"">\d{1}.\d{1})'
$regex3 = '(?<month>PFR<\/span><span class=""right"">\d{2}.\d{1})'
$regex4 = '(?<month>Winnings<\/span><span class=""right"">\-[0-9]{1,9})'
$regex5 = '(?<month>3Bet<\/span><span class=""right"">\d{1}.\d{1})'
Select-String -Path $input_path -Pattern $regex -List | % { $_.Matches} | % { $_.Value } | Foreach-Object {$_ -replace '</span><span class=""right"">', ' = '} | Add-Content $output_file
Select-String -Path $input_path -Pattern $regex2 -List | % { $_.Matches} | % { $_.Value } |Foreach-Object {$_ -replace '</span><span class=""right"">', ' = '} | Add-Content $output_file
Select-String -Path $input_path -Pattern $regex3 -List | % { $_.Matches} | % { $_.Value } | Foreach-Object {$_ -replace '</span><span class=""right"">', ' = '} | Add-Content $output_file
Select-String -Path $input_path -Pattern $regex4 -List | % { $_.Matches} | % { $_.Value } |Foreach-Object {$_ -replace '</span><span class=""right"">', ' = '} | Add-Content $output_file
Select-String -Path $input_path -Pattern $regex5 -List | % { $_.Matches} | % { $_.Value } | Foreach-Object {$_ -replace '</span><span class=""right"">', ' = '} | Add-Content $output_file
')
Register-ObjectEvent $Watcher "Changed" -Action $changeAction
}
Register-Watcher "C:\site-download"
将导致第一次爬坡时的运行时间超过一半，并且每次循环都会进一步改善。
如果我在sum(xrange(10**8))循环中对相同数据运行10次爬山算法（每次爬山进行10,000次迭代），我注意到解决方案的运行时几乎总是会有所下降，最终解决方案占用第一个解决方案所需时间的约50％。每个解决方案唯一计算的是爬坡本身;在所有解决方案之前，诸如距离/时间矩阵和作业列表的支持数据存储在存储器中。 因此，前三个函数仅用于MCVE，可以忽略。
打印输出是运行时后跟for列表，即搜索解决方案时选择新[(iteration_number, greedy_route_cost)]的迭代次数。运行时似乎与每次爬山运行时存储的临时路线数量无关。每个解决方案都应该独立。有人能够在best_route或calc_route_cost中看到加速的原因吗？我在这里缺少什么，我将如何分析这种加速的原因？这是在Python 2.7.9中。
hill_climb答案 0 :(得分：1)
此问题与CPU的资源OS /硬件分配有关，而与CPU分支预测无关。在Windows 7上，同时运行另一个脚本：
for x in range(10):
a = sum(xrange(10**8))
会导致脚本执行的大量加速;与PC处于空闲状态时相比，for p in range(10):的每次迭代仅占用25％的时间。每个循环中的运行时也是一致的。
在Windows 7 中，可以通过以下方式完全解决问题：＃34;设置电源配置文件＆＃34;如在this link中那样。基本上，改变＆＃34; Power Profile＆＃34;进入＆＃34;高性能＆＃34;。
我不清楚为什么sum(xrange(10**8))大幅加速资源的释放，而10万次爬山（10次迭代）迭代并未达到成熟，即使运行时相似且爬山也是如此更复杂。这是一个非常缓慢的滴灌。
在Windows 7中将设置之外的算法标记为高性能似乎是不可能的。在无限循环中运行爬山脚本将在迭代中显示相同的特征，除非您阻止Windows进行限制中央处理器。每次调用脚本时，CPU资源似乎都会重置。