Slow to print long vectors

[Michael D. Adams]

Printing out long vectors has a noticeable delay before getting started. I'm guessing it is doing a cycle check, but the delay is long enough that the first couple times I thought Ikarus had crashed. Whatever it is doing should be profiled and if possible the performance improved.

$ ikarus
Ikarus Scheme version 0.0.3+ (revision 1692, build 2008-11-25)
Copyright (c) 2006-2008 Abdulaziz Ghuloum

> (define x (make-vector #x10FFFF))
> x
<... noticable (3-5 second) delay ...>
#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
...

[Abdulaziz Ghuloum (aghuloum)]

On Dec 2, 2008, at 8:44 AM, Michael D. Adams wrote:

> Printing out long vectors has a noticeable delay before getting
> started.
> I'm guessing it is doing a cycle check, but the delay is long enough
> that the first couple times I thought Ikarus had crashed. Whatever it
> is doing should be profiled and if possible the performance improved.

It's not due to the cycle check. Write/display both do the cycle check
and both come back immediately. It's just pretty-print that's dog slow.

The algorithm that I came up with for computing the layout is
inefficient.
It does pretty-print the code nicely, but at a huge cost as you can see.

There may be places in the pretty-printer that can be improved, but at
its current structure, it will still be slow for other cases. It's
would
be better to fix the algorithm (aka. rewrite the pretty printer) than to
do minor fixes to the implementation.

This is not cheap. It will have to wait for the next fiscal year budget
structuring books to come out to see if we can put this somewhere. :-)

Aziz,,,

[Abdulaziz Ghuloum (aghuloum)]

Marking as wishlist. (the classifications of lanuchpad's "status" and "importance" are pretty sad)