Debug speeds up looping

[billritz]

I had a loop that should have run in a few seconds but it was just sitting there, so I hit ctrl-break to see where it was and it was only within the first hundred records. I hit F5 to continue, and it finished the other 3000 records in a second or two. Puzzled, I limited it to the first 100 records, put in a Timer, and a Stop command after 10 records. The first 10 records took over 3 seconds, and when I hit F5 the next 90 records ran in less than .2 seconds. Has anyone hit anything like that before? BTW, it's version 2013 under Win7 64-bit.

Loop 1: 0.32421875
Loop 2: 0.654296875
Loop 3: 0.955078125
Loop 4: 1.3046875
Loop 5: 1.625
Loop 6: 1.92578125
Loop 7: 2.2265625
Loop 8: 2.55078125
Loop 9: 2.87109375
Loop 10: 3.19140625
Loop 11: 7.94140625
Loop 12: 7.951171875
Loop 13: 7.9609375
Loop 14: 7.9609375
Loop 15: 7.9609375
.
.
.
Loop 88: 8.1015625
Loop 89: 8.1015625
Loop 90: 8.1015625
Loop 91: 8.1015625
Loop 92: 8.111328125
Loop 93: 8.111328125
Loop 94: 8.111328125
Loop 95: 8.111328125
Loop 96: 8.111328125
Loop 97: 8.111328125
Loop 98: 8.111328125
Loop 99: 8.12109375
Loop 100: 8.12109375

 

[AlphaFrog]

Hard to tell without seeing the code. Do you have screen updates and calculations suspended when you loop?

    Application.ScreenUpdating = [color=darkblue]False[/color]
    Application.Calculation = xlCalculationManual
        [color=green]'your loop code here[/color]
    Application.Calculation = xlCalculationAutomatic
    Application.ScreenUpdating = [color=darkblue]True[/color]

 

[billritz]

Sorry, should have said in the original message; the run with the timer had those disabled (along with EnableEvents) - same results. Thanks for the quick reply.

 

[Joe4]

It would be very beneficial to see how your code is written and what it is doing. Something obvious may jump out, if we see it.

 

[billritz]

I didn't include the code because it ran perfectly after the debug/F5, so the actual code wasn't inefficient per se. That said, I found the problem, or at least a working alternative. The code called a function repeatedly that parsed a string and returned the required substring, so it was basically in the form Range("A1") = Parse(string). What I tried was to change the function to a subroutine and passed the location, as: Parse(string, range). Functionally they're equivalent, so I don't get why, but the new one executes almost 3500 lines in about a second - in other words, at the speed you'd expect. that said, I left in the disable/enable of ScreenUpdating, Calculation, and EnableEvents. I hope that this helps someone else, but I still don't know why the original was slow.