There are also other possibilities: Which framebuffer are you using? Is your machine thrashing? Just how slow is it? (It should seem OK on a 1+ -- I'm not sure what is going on here)
Dave
From owner-self@self.stanford.edu Fri Aug 21 16:57:33 1992 Date: Fri, 21 Aug 92 16:55:29 PDT To: rwk@quark.sbi.com Cc: self-interest@self.stanford.edu In-Reply-To: 9208212133.AA18405@quark.sbi.com (rwk@quark.sbi.com) Subject: Self Size
Richard> Why does Self require so much memory?
- Because we trade space for speed in certain places ("memory is cheap").
- Because we have not optimized things for space. I.e. we know how to reduce the size of the code space and the object heap by around a factor of two, but we just haven't gotten around to implementing this space engineering.
Richard> The Self UI runs somewhat slowly. The performance benchmarks Richard> quoted in the various Self documents would make me think the Richard> UI would be quite snappy.
Richard> Why isn't it?
- Because the compiler(s) are sometimes slow (that's why things run slower the first time you do them).
- Because the compilers aren't perfect (yet :-). Note that we do not claim that *all* Self programs are x% of C - just the benchmarks. Also, the default system does *not* use the optimizing compiler for all compilations. Rather, it compiles unoptimized code first (to reduce compile pauses) and reoptimizes later when it sees that some code is frequently used. Unfortunately, the system doesn't always recompile the right thing, so the resulting code may be slower than if it had been compiled in optimizing mode the first time.
Richard> I am a fan of Scheme and its functional syntax. Could a Richard> functional "front end" be written for Self? Not necessarily Richard> Scheme compatible, just "lisp-ish".
I guess it could...just try it! :-)
-Urs
PS: We're actively working on both the space and the speed problems!
There are also other possibilities: Which framebuffer are you using?
I'm not sure what framebuffer I am using. I'm sure it is the low-end standard 19" color monitor that came with 1+'s.
Is your machine thrashing?
I have 40 meg of real memory. I am sure it is not thrashing (I would hear it).
Just how slow is it?
It probably takes from 0.3 to 1.0 seconds or so to sprout. Also when I grab and drag, it sometimes misses it entirely and othertimes nothing happens for a second and then the object jumps to the location of my mouse.
(It should seem OK on a 1+ -- I'm not sure what is going on here)
Also, it doesn't really seem to be any slower at first, and then get faster with use. But there is quite a bit of variability in the response of identical actions.
Hope this helps and I am pleased to hear the size and performance issues are being worked on.
Dick
Richard W. Kreutzer Consultant writes:
There are also other possibilities: Which framebuffer are you using?
I'm not sure what framebuffer I am using. I'm sure it is the low-end standard 19" color monitor that came with 1+'s.
If it isn't a GX, it will probably be markedly slower. GX's don't do much, but what they do (big blits) they do very fast.
Just how slow is it?
It probably takes from 0.3 to 1.0 seconds or so to sprout. Also
when I grab
and drag, it sometimes misses it entirely and othertimes nothing
happens for a
second and then the object jumps to the location of my mouse.
This behavior sounds like something I stumbled on when I finally got a demo from the Self guys (hi guys!)
The machines where I usually work either have "low" amounts of ram (e.g., 24megs) or have funny framebuffers (a GS barely works -- the colormap stuff and overlay planes dont' work the same as on a GX, but at least you can see something -- a GT doesn't work at all). So I never saw the self UI really doing its thing until just recently.
I saw essentially the same behavior, but in a predictable fashion: If you click on an object and move off of it fast enough, nothing happens until you move the mouse again, at which point the object snaps to the mouse point. So click, move fast, and _stop_. Wait as long as you like, and nothing will happen. Then jiggle the mouse, just a bit, and the object jumps to the mouse position.
So, whoever wrote that part of the code goofed a bit on their event handling routine.
Brook
self-interest@lists.selflanguage.org
-
David.Ungar＠Eng.Sun.COM -
dbc＠cs.brown.edu -
rwk＠quark.sbi.com