I have a feeling you're right.

I did notice however that the amount of lines per pass makes a big difference in the overall result.

In my example, I used 50 lines per pass which took 26 minutes. Using your code with 1000 lines per pass dropped it down to 11 minutes on the laptop I use.

I did try and manipulate timers once again thinking it is a memory thing. I'm not too technically minded about software, but my thoughts were that a certain amount of memory is allocated each time loadbuf executed (which clears once the event is finished), and if its executed several times before the first pass is over, you are simply allocated more memory at the expense of speed, and not allowing it to clear.

Anyway, like I said I'm not that knowledgable about the inner workings of software so I can be excused it all of the above is nonsense. But what I did try to do was space out the timer so that instead of being called immediately, it would occur every 3 seconds. That didn't make any difference.

Next, I tried to increment the timer, so that every time it reached a 10000 mark in the lines it was to buffer, it would increment one second,

I used the %y variable in the timer which started at zero & change the following line in testit
Code:
timeraddline %c %y addline $!calc( %c - $!timer(addline).reps)


as well as:
Code:
  
alias addline {
  var %t = $ticks
  var %a = $1
  if (10 // %a) { inc %y }  
  loadbuf $+($calc(%a * 1000 - 999),-,$calc(%a * 1000)) -o big 1 %f
  echo -st Doing $+($calc(%a * 1000 - 999),-,$calc(%a * 1000)) . Ticks taken so far $calc($ticks - %ticks) , this pass $calc($ticks - %t)
}


Anyway, that didn't work either. Then I tried to create a "pause" every 20000 lines, thinking, if the whole process were to pause for a second or two, it would allow some memory to be freed up then continue fresh at a faster speed.

so instead of increasing %y, it remained 0, but instead i changed my line in addline to:

if (20 // %a) { var %v = 1 | while (%v <= 100000) { inc %v } | echo -st Pause }

Anyway. That only made the whole thing take longer than 11 minutes.

So anyway, I think the only real solution can't be found in scripting a solution to this, but rather with performance enhancing dll's - at least until this bug is fixed (if it can even be called a bug - it's probably more a case of me trying to do something that dialog lists were never designed for)