guile-user
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]