[PATCH] Move slow path out of 'scm_get_byte_or_eof' et al

2013-04-02 Thread Mark H Weaver
Andy suggested this. Okay to push to stable-2.0? Mark From 0b70eba61ee26654f442199e7cc49838c5b0030e Mon Sep 17 00:00:00 2001 From: Mark H Weaver m...@netris.org 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

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

2013-04-02 Thread Daniel Llorens
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

Re: [PATCH] Move slow path out of 'scm_get_byte_or_eof' et al

2013-04-02 Thread Mike Gran
From: Mark H Weaver m...@netris.org    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.  

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

2013-04-02 Thread Daniel Llorens
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 goes on

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

2013-04-02 Thread Daniel Llorens
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

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

2013-04-02 Thread Daniel Llorens
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

Re: Extremly slow for format string-join

2013-04-02 Thread Ludovic Courtès
Mark H Weaver m...@netris.org 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)

Re: [PATCH] Move slow path out of 'scm_get_byte_or_eof' et al

2013-04-02 Thread Ludovic Courtès
Mike Gran spk...@yahoo.com skribis: From: Mark H Weaver m...@netris.org    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

Re: [PATCH] Move slow path out of 'scm_get_byte_or_eof' et al

2013-04-02 Thread Mark H Weaver
Mike Gran spk...@yahoo.com 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

Re: [PATCH] Move slow path out of 'scm_get_byte_or_eof' et al

2013-04-02 Thread Mike Gran
From: Mark H Weaver m...@netris.org 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