hello Jeremy,

i just have a glance at your source code and it is more developped than the guile version which i personally ported to racket so it would be hard to compare (in term of speed,etc) also i never used chicken ,just guile and racket but i will use chicken in future as i want to port my Scheme+ to chicken as it has the necessary srfi 105.

I did not know SRFI 42, using Python ,i see it provides what Python has : comprehension and i will use it for sure to port code from Python to Scheme. In contrast to Python i think Scheme miss some feature , for example in Python you can declare a hashtable like this :

dict  =  {'Name':  'Zara',  'Age':  7,  'Class':  'First'}

but not in Scheme ,i want to add such feature (if no srfi alread do it) in Scheme+.

Damien

Le 17/04/2023 à 06:25, Jeremy Steward a écrit :
Hey Damian, I must have missed this message when I announced v0.3.0.

On 4/3/23 00:08, Damien Mattei wrote:
Hello,

does this transducers implementation add some significant speed to code
when using them? i ask the question because i used transducers with
Guile with very poor speed improvement compared to normal code.


This question is going to be difficult to answer in any meaningful way. For starters, I'll assume you're using SRFI 171 with Guile?

Relative to the SRFI-171 base implementation, I'm not sure that the transducers library I've written is ever going to be "faster" than a hand-written / hand-optimized loop. I assume this is what you mean by "normal code." I believe SRFI 42 can be significantly faster, but is considerably different in terms of both purpose and implementation.

Nevertheless, I think there's a problem with the way the question is posed. Some thoughts:

- "normal code" is ill-defined here, and I think it's counter-intuitive to think about libraries relative to code with zero abstractions in terms of performance alone, especially in Scheme. Generally speaking, I'd say that if you can get good performance with what code you have and you don't see a maintenance problem, then maybe an abstraction isn't necessary.

- Asking about SRFI-171 in Guile relative to transducers in CHICKEN seems like it has a bunch of problems on its own. CHICKEN can generally be faster than many Scheme implementations but there's a wide number of reasons that code on Guile may perform worse or better.

- You've provided no real indication of what you were doing. It would be difficult to say how transducers might help improve (or not improve) performance for some nebulous set of problems.

Anyways, this is not to lambast you for the question -- I'm sure it comes from a genuine place. I'd encourage you to try the library out and use CHICKEN's profiler (call your application with the argument "-:p" without quotes, see <https://wiki.call-cc.org/man/5/Using%20the%20compiler#runtime-options>). It's often better to measure what you can and then make a decision from there.

I'd also encourage you to read the documentation for transducers if you haven't already - it should give you an idea of what is being done and what kind of performance to expect (<https://wiki.call-cc.org/eggref/5/transducers>).

Reply via email to