Andy suggested this. Okay to push to stable-2.0?
Mark
>From 0b70eba61ee26654f442199e7cc49838c5b0030e Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 2 Apr 2013 05:33:24 -0400
Subject: [PATCH] Move slow path out of 'scm_get_byte_or_eof' et al.
Suggested by Andy Wingo.
* libguile/i
On Apr 1, 2013, at 19:15, Daniel Llorens wrote:
> Third, none of the above are causing the slowness of array-copy!. I noticed
> that there's a double indirection in racp(). The second patch removes it.
> Actually this double indirection goes on all over array-map.c and I don't
> understand why
> From: Mark H Weaver
>
>Andy suggested this. Okay to push to stable-2.0?
Hi Mark,
I can't imagine any possible way that this patch could make
performance worse, but, it is in the very core of the ports.
I don't think you can get away without at least a bit of
profiling.
-Mike
On Apr 2, 2013, at 12:19, Daniel Llorens wrote:
> On Apr 1, 2013, at 19:15, Daniel Llorens wrote:
>
>> Third, none of the above are causing the slowness of array-copy!. I noticed
>> that there's a double indirection in racp(). The second patch removes it.
>> Actually this double indirection go
On Apr 2, 2013, at 12:19, Daniel Llorens wrote:
> On Apr 1, 2013, at 19:15, Daniel Llorens wrote:
>
>> Third, none of the above are causing the slowness of array-copy!. I noticed
>> that there's a double indirection in racp(). The second patch removes it.
>> Actually this double indirection go
This patch is for array-for-each. Only the first argument.
Before:
scheme@(guile-user)> (define a (make-array 1 100 10))
scheme@(guile-user)> ,time (let ((x 0)) (array-for-each (lambda (a) (set! x (+
a x))) a) x)
$8 = 1000
;; 0.621887s real time, 0.620181s run time. 0.00s spent in
Hello,
sorry for the repeated message earlier.
Ok, i think it's clear that all these double indirections can be eliminated
globally by composing the strides of the array descriptor with the stride of
SCM_I_ARRAY_V (array) and using that directly in the array descriptor. Is there
any reason n
Mark H Weaver skribis:
> Indeed, the implementation of 'string-join' was very bad: about O(n^2)
[...]
> Before:
>
> scheme@(guile-user)> ,time (define s (string-join (make-list 1 "test")
> "-"))
> ;; 0.998800s real time, 0.996677s run time. 0.984885s spent in GC.
> scheme@(guile-user)> ,t
Mike Gran skribis:
>> From: Mark H Weaver
>>
>>Andy suggested this. Okay to push to stable-2.0?
>
> Hi Mark,
>
> I can't imagine any possible way that this patch could make
> performance worse, but, it is in the very core of the ports.
>
> I don't think you can get away without at least a
Mike Gran writes:
> I can't imagine any possible way that this patch could make
> performance worse, but, it is in the very core of the ports.
>
> I don't think you can get away without at least a bit of
> profiling.
Fair enough. First of all, this patch reduces the size of the built
libguile
> From: Mark H Weaver
> Thanks for nudging me to do the measurement. To be honest, the original
> patch I posted slowed things down by 4.5%, which I found extremely
> surprising. I fixed it by adding an internal 'static' version of
> 'scm_fill_input'. So for those who doubt the cost of functio
11 matches
Mail list logo
