Hey Jacob,
Thanks for the feedback
Who would of thought this would be quite such a contentious issue?! I feel quite the first year student getting grilled by the heads of school 
The big point here is that there is no Dynamo ‘stop run’ button… If you kill it, you lose everything.
I’m suggesting using this code to avoid killing Dynamo when stuck in an infinite loop or if I accidentally created a graph/code which would take unreasonable amount of time to run.
If your graph usually takes 10 seconds, and it’s taking more than 10x the time,
I don’t think that’s the problem, if it executes in a ‘short’ time I can live with that. It’s if killing Dynamo is quicker that letting it finish.
I would be very interested in tips to make python or graphs more efficient, perhaps we should start a dedicated thread?
Could be n^2 testing, overly large data set, element binding issue, or complex relationship with other elements in the Revit model, or anything really
If this was accidental, then you want it to stop, you’ll get to see how far through it went and you can re-evaluate. If it was what you wanted and it took too long, at least you (have a crude) way of narrowing down which was the slow bit. Maybe initially you set it to 10 seconds, then 100, then 1000… you can see where the bottle necks are, but heck, maybe it does just need 2 weeks, just like Erik’s students. You’d only be running it if it saved you a few months worth of manual work, or was just impossible without Dynamo.
Stopping said actions mid-way though will either cause you to have to start the ‘long’ process a second (third, nth) time (saving you nothing).
As stated above, perhaps the final python had a simple mistake and the entire rest of the graph has executed, now you can see how far that node got, fix it and run to completion. Quite a saving.
Or worse yet could lead to failed updates on the second run so you’ll think you finished, but because the part which was timing out didn’t re-run you’ll get mis-matched lists and easily process the remainder of the content, missing out of processing a sizable chunk of data.
I would suggest integration of a window which pops up to tell you that a node did not run to completion.
If you are forced to kill it, perhaps the bit you thought was broken isn’t and you rerun to have the same error force you to kill, open, run again… let’s imagine that process takes you hours… that’s painful.
Let’s imagine that you did actually fix it in one of those attempts, only for a second error to occur. in this workflow there’s nothing to tell you that, you keep trying to fix the first problem.
If it exits of its own accord you get feedback which you can use to inform your process… That’s why this is useful.
But yeah, I’ll use it and just not tell you
(that’s my strategy when told to use Autocad or Sketchup) I’ll let you know how I get on, if it turns out to be a dumb idea, I’m quite happy to tell you all!
Have a great Christmas,
Mark