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>