Hi,
On Wed 25 Apr 2012 01:14, l...@gnu.org (Ludovic Courtès) writes:
> Would be nice to check with the micro-benchs in vlists.bm as well.
Forgot to mention that.
Before:
;; running guile version 2.0.5.94-a8004d
;; calibrating the benchmarking framework...
;; calibration: ("empty initiali
Hi,
Andy Wingo skribis:
> I don't think it's useful to run srfi-1 and vlist tests the same number
> of times when their complexity varies, as in the assoc case.
Right, and the ‘vhash’ bench is too short to draw any sort of conclusion.
Could you try with an appropriate value of ‘--iteration-fac
Hello all,
There has been some talk on this list about letting Guile show useful
backtraces for tail-recursive functions. I was thinking about how to
optimize local variable allocation, and realized that this question is
related to that, and to other things too. So I'd like to ask people
now how w
On Wed 25 Apr 2012 16:10, l...@gnu.org (Ludovic Courtès) writes:
>> I don't think it's useful to run srfi-1 and vlist tests the same number
>> of times when their complexity varies, as in the assoc case.
>
> Right, and the ‘vhash’ bench is too short to draw any sort of conclusion.
>
> Could you tr
Hi Andy!
Andy Wingo skribis:
> For what it's worth, the current overhead of the benchmark appears to be
> about 35 microseconds per iteration, on my laptop. If we inline the
> iteration into the benchmark itself, rather than calling a thunk
> repeatedly, we can bring that down to around 13 micr
Hi,
Sjoerd van Leent skribis:
> When compiling I get to the generation stage of GEN guile-procedures.texi.
> The stage ends up with a Segmentation fault. I have been debugging the
> lt_guile process with gdb, and some interesting things happened. The
> process received SIGPWR and SIGXCPU signals
