At a glance, the below is some damned fine sleuthing. Excellent work.
On Dec 14, 2011, at 5:51 PM, Christopher Oliver current.input.port@gmail.com wrote:
I spent a bit of time working backwards from the user interrupt watcher process:
InputSensor>>userInterruptWatcher SmalltalkImage>>handleUserInterrupt MorphicProject>>interruptName: MorphicProject>>interruptName:preemptedProcess: Debugger class>>openInterrupt:onProcess: SmalltalkImage>>logSqueakError:inContext: SmalltalkImage>>logError:inContext:to: ContextPart>>errorReportOn: MethodContext>>printDetails: ContextPart>>tempsAndValuesLimitedTo:indent: Object>>printStringLimitedTo:
The story runs as follows: you're more than likely to interrupt '100000 factorial' in SmallInteger>>* since that's the bulk of the computation, and the argument aNumber is more than likely a LargePositiveInteger. When ContextPart>>errorReportOn: displays this, the bignum is converted to a decimal string and then truncated, and this appears to be the source of the delay. Nothing prior to or following the invocation of Object>>printStringLimitedTo: takes much time at all. This suggests that vars in the first twenty frames (see ContextPart>>errorReportOn:) that have a string representation that's expensive to compute will make Smalltalk appear to hang on cmd-. I can appreciate value in being able to look at the stack dump in SqueakDebug.log to determine where Smalltalk was when you hit the interrupt key, so I'm at a loss how is best to go here.
Thoughts?
-- Christopher Oliver current.input.port@gmail.com