One of my experiences is that it matters less how fast something 
actually is, rather than the expectation that something is about to 
happen.  For example, it was a very effective OR solution in 
"optimizing" elevator waiting time, merely to put mirrors up so 
individuals waiting for an elevator have something with which to occupy 
themselves while waiting a reasonable time.

The user experience in Squeak is to display a partial, empty window 
while doing some silliness involving data operations, and upon the 
completion of the silliness, expands and begins to display the window.  
The display of the partial window creates an expectation in the minds of 
users that something is about to, and should, happen.

If, instead, we were to display a banner of some kind (modifiable by 
changing a resource file for particularized applications), preflight and 
complete the I/O off-screen, and only then show the window when 
complete, the end-experience of the start-up would be substantially 
crisper and snappier.

Strongly suggest doing this as a matter of course -- displaying a 
partial, and unexpanded, window with nothingness is a bad idea as a 
matter of system interface design practice.

On Wednesday, January 2, 2002, at 02:31  AM, John M McIntosh wrote:

> I've been looking into this. I've noticed on windows why when you 
> startup Squeak it just snaps up! But it takes seconds on the mac, why?
>
> Thanks to some OS-X tools, let alone the usage of fs_usage I've noted 
> that 3.2.1B5 does 1,574 I/O operations in order to startup. By apply 
> some thought to how plugins are looked for I've cut that to 902 I/Os
>
> Right now I get timings of
> 11ms to start main to the point of image reading
> 1,852ms to read a 15,1903,04 file, 7.8MB sec?
> 386ms to fixup image.
> 1,250ms to first update screen event in the interpreter.
>
> I'm considering mmap and other interesting things to perhaps speedup 
> the read, along with more review of how the directory lookup logic and 
> directory entries logic works. (Somewhat ugly due to the transition to 
> os-x).
>
>
> Let alone how the startup code hunts for the changes and source file, 
> and why we need to tap the nonexistent applescript plugin at startup 
> time.
>
> So I'm wondering if there are some suggestions out there.
> -- --
> =========================================================================
> ==
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =========================================================================
> ==
>
>