Re: [Jscheme-user] stack overflow in {}

[Ken A. <kan...@bb...>]

The problem is not with the number of lines, but with displaying a single 
line.  This code shows the problem:

(define (gen n)
   (let loop ((n n)
              (sofar '()))
     (if (= n 0) sofar
         (loop (- n 1) (cons n sofar)))))

;;; Xemacs 21.4  Gnu Emacs 20.7.1
(define (t1 n)                            ; 13 sec        51 sec
   (time (begin (for-each print (gen n)) #t) 1))

                                         ; 152 sec      120 sec cursor at 
bottom
(define (t2 n)                          ;   2 sec       98 sec cursor at top
     (time (begin (print (gen n)) #t) 1))

{
Xemacs 21.4
t1:
n      #chars  time(sec)
25000   138894  3.445    time = n/10000 + 0.245
50000   288894  6.579
100000  588895  12.978

t2:
25000   138895  9.294    time = 2e-08n^2 + 0.0001n + 1.8
50000   288895  37.143
100000  588896  153.862

Gnu Emacs 20.7.1

25000   138894  11.126   time = 4*n/10000
50000   288894  18.918
100000  588895  42.202

25000   138895  11.857   time = 7e-09n^2 0.0005x - 6
50000   288895  38.482
100000  588896  118.050

If you run (t1), it prints 100,000 integers to the screen in about 13 seconds.
If you do (t2) it takes 2 minutes to print the list of 100,000 integers, 
588,896 characters long.

The problem is formatting the output with the cursor at the bottom of the 
buffer.  If you move the cursor to the top of the buffer before printing is 
much faster in Xemacs and a little faster in Gnu EMACS.

While the printing is happening, XEMACS is completely unresponsive, while 
Gnu EMACS is fairly responsive.

So a million character list takes about 8 minutes to display, and an 8 
million character list takes almost 9 hours.  So i try not to print them.
At 04:32 AM 8/13/2002, Geoffrey S.Knauth wrote:
>I'm very surprised to hear that Emacs had a memory problem holding all 
>this output, since in Emacs terms, 35,000 is still a relatively small 
>number.  I've used Emacs to examine files that were hundreds of megabytes 
>in size.  Ten years ago, however, there was an 8MB limit.
>
>I wonder if the Emacs behavior you saw, not being able to hold all the 
>output, was a side effect of the Emacs mode you were in.  You wrote that 
>you didn't have line breaks.  Perhaps you were in a mode that looked for 
>line breaks in order to do font/color customization, and the mode lost its way.
>
>Just out of curiosity, try M-x text-mode or fundamental-mode on your 
>output buffer before generating huge output, just to see if that keeps 
>Emacs from boiling over.  Also, see if you are using a relatively recent 
>Emacs (M-x emacs-version).
>
>Geoffrey
>
>On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:
>
>>Rusty an i have been data mining with lists of 35,000 items.
>>Things work reasonably OK as long as you don't print them as a list to 
>>EMACS without any line breaks.  I usually kill my Jscheme at that point 
>>and start over.
>>
>>I've truncated error messages to 1000 characters which helps a lot with 
>>reporting bugs.  Perhaps we should have parameter that effects the REPL, 
>>to help reduce the cost of accidents.  Common Lisp had several, such as 
>>print-length and print-level, but one might work for us, were small.
>>
>>We have one example of using {} to generate a web page, with at least a 
>>1300 row x 5 columns x 3 string
>> > 19,500 Jscheme frames - leads to a stack overflow.  This seems pretty 
>> tiny, but
>>the simple experiement:
>>(define (grow n)
>>   (if (= n 0) '()
>>       (cons n (grow (- n 1)))))
>>(define (size n)
>>   (print n)
>>   (grow n)
>>   (size (+ n n)))
>>(size 1)
>>
>>produces:
>> > 1
>>2
>>4
>>8
>>16
>>32
>>64
>>128
>>256
>>512
>>1024
>>2048
>>An unrecoverable stack overflow has occurred.
>>
>>We were able to rewrite the page in a dumb string-consing accumulator 
>>style and get the result we wanted.
>>
>>Is there an alternative way we can write !{}?
>>
>>k
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: Dice - The leading online job board
>>for high-tech professionals. Search and apply for tech jobs today!
>>http://seeker.dice.com/seeker.epl?rel_code=31
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user