David Kastrup <d...@gnu.org> writes: > Arne Babenhauserheide <arne_...@web.de> writes: > >> I implemented a version which avoids both points via let-recursion and >> number->string: >> >> (define (make-bgl lis cnt) >> "a bogus longer list" >> (let loop ((longer (cons (number->string cnt) lis)) >> (cnt cnt)) >> ;; periodically report statistics >> (when (eq? 0 (modulo cnt (* 1000 1000))) >> (begin (format #t "~A " cnt) (avg-gc-cpu-time))) >> (cond >> ;; periodically trim the list >> ((and (eq? 0 (modulo cnt (* 4123 1123)) (> (length longer) 0))) > > You probably mean > > ((and (eq? 0 (modulo cnt (* 4123 1123))) (> (length longer) 0)) > > instead, and (eq? 0 ...) is undefined behavior anyway even disregarding > that it let an error go unnoticed that would have bombed out had you > been using (= 0 ...) or equivalently (zero? ...) instead.
Ah, yes, there’s the memoryleak. Thank you! > And (> (length longer) 0) is just horribly inefficient anyway (O(n) with > a turtle-hare hiding in the constant factor) compared to (pair? longer). I didn’t know that this works — thank you! (pair? (list)) → #f (pair? (list 1)) → #t >> This does indeed spend much less time in GC, but its memory usage is >> still rising rapidly. Did I unknowingly create a memory leak? Thanks to David this is answered now. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
