CLIM mail archive
[Prev][Next][Index][Thread]
Re: reducing time overhead of text display (in 1.1)
Date: Mon, 20 Dec 1993 18:26 EST
From: Jeff Morrill <jmorrill@BBN.COM>
I can't resist commenting on this.
==================
Date: Mon, 20 Dec 1993 16:09 -0500
From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
So with the above in mind, here's a brief answer, with some comparisons
thrown in against C/C++ as well.
- If you're using C or C++, you are using a language most of whose
compilers produce good code with almost no function calling overhead.
When you are doing lots of function calling, C still beats Lisp every
time. CLIM does a lot of function calling.
Actually, Lisp and C are pretty equivalent when it comes
to the amount of time required for one function call (.5 microseconds
on a Sparc). Where C wins big is that some optimizing compilers will in-line
virtually everything and eliminate the function calls altogether.
- Method dispatching in CLOS has to be done completely at run-time. It
can often be done with no overhead in C++.
Yes, C++ method dispatching is often compiled into a function call.
Often, C++ programs have no run-time dispatching. (C++ is virtually an
object-oriented language!)
Don't forget that clim uses &rest and &key profusely. These are inherently
slow and should have been avoided for operations that are supposedly efficent.
For example, every time I call DRAW-LINE*, clim has to take apart all those
keywords just in case I want dotted lines (even though I never do). Using
&rest or &key increases the cost of a function call by as much as an
order of magnitude.
Actually, CLIM has a bunch of compiler macros that pick apart some of the common drawing
function idioms, and generate calls to functions that take position arguments. It doesn't catch
everything, but it does part of the job.
==================
Date: Mon, 20 Dec 1993 14:39 EST
From: Peter Karp <pkarp@ai.sri.com>
Believe me, I appreciate CLIM's high-level capabilities or I wouldn't
be using it. But I believe that a measure of high-level snottiness
has gotten in the way of getting CLIM to do simple things quickly.
I don't think we should define presentations as "simple things."
Generating one presentation should take an amount of time equivalent
to calling MAKE-INSTANCE plus inserting it into a sorted output history
plus capturing all the devious things you can do with the WITH-xxx macros.
These things are unavoidable. If it takes longer than this, then
perhaps we have something to complain about.
My metering has always indicated that creating a presentation doesn't take any longer than I
expect given what it has to do. That is not to say that there is no room for improvement, just
that there are no obvious things to tweak any more.
==================
It should come as no great surprise that calling MEDIUM-DRAW-TEXT* on
the medium (rather than the sheet or stream) is *much* faster than
calling DRAW-TEXT* and doing output recording.
MEDIUM-DRAW-TEXT* is what I call a "simple thing". Drawing a character
(or a string) with no output recording should be fast. I benchmarked DRAW-CHAR
at 9 microseconds for file I/O. I don't know what it would be for a window,
but presumably it is nearly as fast and doesn't cons.
Yes, MEDIUM-DRAW-TEXT* on a medium is "simple".
Note however that PRINT can be a real dog, even without output recording.
Printing a floating-point number typically takes around 1000 times
longer than printing it's component characters. This is because of the
bignums that get consed figure out which digit comes next. (Bignums?!)
CLIM implementors didn't write these horrid algorithms, but it can be a
factor in the user's impression of clim performance.
Many floating point printers use bignums in order to retain precision when printing fractions
with lots of significant digits. Genera keeps a table of bignums for this purpose, and doesn't
typically need to cons to do it.
jeff morrill
jmorrill@bbn.com
References:
Main Index |
Thread Index