[Openmcl-devel] I knew format was slow, but this slow ??

Gary Byers gb at clozure.com
Thu Oct 2 11:45:57 PDT 2003

On Thu, 2 Oct 2003, Sven Van Caekenberghe wrote:

> On Thursday, October 2, 2003, at 07:32 PM, Gary Byers wrote:
> > On Thu, 2 Oct 2003, Sven Van Caekenberghe wrote:
> >
> >> I knew format was slow, but can it be really this slow ??
> >>
> >> Note that the difference between 10 and 100 iterations in the first
> >> loop results not in a 10-fold difference in time, but a 100-fold
> >> difference - so its gets exponentially slower !
> >>
> >> The write-string version is almost a 1000 times faster, is this still
> >> normal ? Also note the extreme differences in memory allocation.
> >
> > Not that it should be (very) relevant, but what was the value of
> > *PRINT-PRETTY* when you tried this ?  Of (the even less relevant)
> ? *print-pretty*
> T
> ? *print-circle*

Just setting up the context for the pretty printer (that's also used for
circularity detection) is the culprit here.  I suppose that it's bad
enough when there are format directives involved, but if you're just
trying to use FORMAT to write a string to a stream, it's really, really
bad (as you saw.)

If there aren't any format directives (#\~) in the control string, I
-think- that *PRINT-PRETTY* can be ignored (and obviously circularity
detection isn't an issue.)  Assuming that that assumption's correct
(and that things like misering aren't an issue), it would pay to check
for that before sailing off into the pretty printer.  There's a COND
near the end of the FORMAT definition (in "ccl:lib;format.lisp") that
could be changed to:

	      ((and (or *print-pretty* *print-circle*)
		    (not (typep stream 'xp-stream)))
		#'(lambda (s o)
		    (do-sub-format-1 s o))
		stream format-arguments))
		[ ...])

There might be slightly better ways to do that, but it seems like it'd
be worthwhile to only invoke the pretty printer if pretty-printing -might-
do something ...

Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list