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,
These timings loop pretty good. The file read time seems consistent with other bulk-read operations I've timed. I believe file reading is about 5-6 MB/sec on a Powerbook.
I'm not sure mapping the file will be faster, although I think that's what windows does, since we have to scan the heap to fixup the image, so we probably have to page in most of the heap anyhow.
What's happening during the 1250 msecs between fixing up the image and the first update screen event? I imagine that this time is spent running Squeak startup code, which includes allocating the Display bitmap, opening the sources files, etc. With a bit of cleverness, we could probably use MessageTally to profile this code.
Good work cutting the I/O ops almost in half!
-- John
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.
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@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ========================================================================= ==
"Andrew C. Greenberg" werdna@mucow.com is widely believed to have written:
One of my experiences is that it matters less how fast something actually is, rather than the expectation that something is about to happen.
Exactly - basic UI rules that we knew about thirty years ago. It amazes how often it is ignored in 'modern' software.
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.
This is really dumb. There is no need to create the window until and unless the beDisplay primitive is called. (possibly one might need some sort of window under some OSs in order to get events?) The change is really simple - that's how it works on Acorn and I did once do it for unix as well. It makes a headless system simpler; you just don't call the beDisplay method and no window appears. Duh.
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.
That would be sensible for many cases. It could be done via platform resource stuff or maybe even by sticking a bitmap in the image in a known place guaranteed to be uncompressed and available to the vm in short order? Pixel-endianness might be an issue but it probably survivable.
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.
Abso-bloomin-lutely.
tim
"Andrew C. Greenberg" werdna@mucow.com is widely believed to have written:
One of my experiences is that it matters less how fast something actually is, rather than the expectation that something is about to happen.
Exactly - basic UI rules that we knew about thirty years ago. It amazes how often it is ignored in 'modern' software.
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.
This is really dumb. There is no need to create the window until and unless the beDisplay primitive is called. (possibly one might need some sort of window under some OSs in order to get events?) The change is really simple - that's how it works on Acorn and I did once do it for unix as well. It makes a headless system simpler; you just don't call the beDisplay method and no window appears. Duh.
Go on, add to my work load during year end taxes, of course I'm quite willing to find some way to escape the paperwork.
I did look at this a while back, but it seems there are one or two places where we grab the window information, OpenGL for example, and during the startup phase. However it occurred to me that I can just hide the window, then display it on the first real need for the window. I'll consider an about box too. This has been missing *forever* in Squeak and it's about time it was added...
squeak-dev@lists.squeakfoundation.org