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 at 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 at gmail.com>
>