[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: out-of-control GC
From: |
Arne Babenhauserheide |
Subject: |
Re: out-of-control GC |
Date: |
Wed, 13 Sep 2017 22:37:21 +0200 |
David Kastrup <address@hidden> writes:
> Arne Babenhauserheide <address@hidden> 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
Re: out-of-control GC, Arne Babenhauserheide, 2017/09/10
Re: out-of-control GC, Mark H Weaver, 2017/09/12
Re: out-of-control GC, Linas Vepstas, 2017/09/14
Re: out-of-control GC, Hans Åberg, 2017/09/11
Re: out-of-control GC, Kjetil Matheussen, 2017/09/11