Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
Kon, You noted in this thread that you had ported csv-xml for your own purposes. Would you be willing to share your changes, or could we get this into the released system? Also, even though Ivan mentioned that the csv egg had been superseded, is anybody interested in getting that ported to chicken 5? I think it would be helpful to users porting chicken 4 code to chicken 5 to be able to have this there. Thanks, Jeff
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
Awesome, thanks! On Thu, Jan 9, 2020 at 4:14 PM Kon Lovett wrote: > attached is the compressed trunk > > it uses the utf8 egg + a couple of my eggs > > > On Jan 9, 2020, at 3:01 PM, Jeff Moon wrote: > > > > Kon, > > You noted in this thread that you had ported csv-xml for your own > purposes. Would you be willing to share your changes, or could we get this > into the released system? > > > > Also, even though Ivan mentioned that the csv egg had been superseded, > is anybody interested in getting that ported to chicken 5? I think it > would be helpful to users porting chicken 4 code to chicken 5 to be able to > have this there. > > > > Thanks, > > Jeff > > > > > >
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
attached is the compressed trunk it uses the utf8 egg + a couple of my eggs > On Jan 9, 2020, at 3:01 PM, Jeff Moon wrote: > > Kon, > You noted in this thread that you had ported csv-xml for your own purposes. > Would you be willing to share your changes, or could we get this into the > released system? > > Also, even though Ivan mentioned that the csv egg had been superseded, is > anybody interested in getting that ported to chicken 5? I think it would be > helpful to users porting chicken 4 code to chicken 5 to be able to have this > there. > > Thanks, > Jeff > > <>
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
> call-with-environment-variables > csv > csv-xml > dot-locking > foof-loop > hostinfo > pathname-expand > ports > regex-case > rpc > s11n > sparse-vectors > srfi-12 > srfi-19 > tcp Dot-locking, regex-case and s11n have been ported. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
On Sat, Sep 28, 2019 at 11:27:49AM -0700, Matt Welland wrote: > foof-loop I've just ported this to CHICKEN 5, from the original upstream sources. It should be available shortly. Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
The csv egg in Chicken 4 has been superseded by tabular in Chicken 5, which offers a generalized interface for parsing tabular text data, including fixed-width columns. -Ivan On Sat, Sep 28, 2019 at 11:28 AM Matt Welland wrote: > > On Sat, 2019-09-28 at 19:18 +0200, Jörg F. Wittenberger wrote: > > Am Fri, 27 Sep 2019 23:27:23 +0200 > > schrieb felix.winkelm...@bevuta.com: > > > > > > Hi all, > > > > > > > > Attached is a relatively straightforward patch for SRFI-13. It > > > > changes the let-string-start+end macro (and also > > > > let-string-start+end2 but that isn't exported) so that it uses > > > > let-optionals* and the entire picking apart of the rest arg list > > > > into start/end can be completely inlined, as well as checking the > > > > values against the string length(s). > > > > > > Wonderful! Applied and tagged (0.3). > > > > Would it make sense to apply this also on Chicken 4? > > > > I see the latter living for quite a while. > > > > If nothing else than if it just was for me. :-/ > > It will be a while before I can migrate away from Chicken 4 so count me > among those who would be appreciative of any porting of > fixes/improvements from chicken 5 to 4. I'm keen on getting to Chicken > 5 as soon as possible but it is a large task and is likely to take six > months to a year. > > NOTE: Aside from the effort in porting the code there are still a few > dependencies on eggs that have not been ported. Triming dependencies > may eliminate some of these. A quick crude scan of use statements gave > me this: > > call-with-environment-variables > csv > csv-xml > dot-locking > foof-loop > hostinfo > pathname-expand > ports > regex-case > rpc > s11n > sparse-vectors > srfi-12 > srfi-19 > tcp > > > > > > ___ > > Chicken-hackers mailing list > > Chicken-hackers@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/chicken-hackers > > > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
> NOTE: Aside from the effort in porting the code there are still a few > dependencies on eggs that have not been ported. Triming dependencies > may eliminate some of these. A quick crude scan of use statements gave > me this: > > call-with-environment-variables > csv > csv-xml > dot-locking > foof-loop > hostinfo > pathname-expand > ports > regex-case > rpc > s11n > sparse-vectors > srfi-12 > srfi-19 > tcp csv-xml ported - for my own purposes srf-19 is waiting on srfi-29, which is waiting on me figuring out how to install bundles w/ .egg (custom build scripts, *nix & win, probably) ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
> NOTE: Aside from the effort in porting the code there are still a few > dependencies on eggs that have not been ported. Triming dependencies > may eliminate some of these. A quick crude scan of use statements gave > me this: > > call-with-environment-variables > csv > csv-xml > dot-locking > foof-loop > hostinfo > pathname-expand > ports > regex-case > rpc > s11n > sparse-vectors > srfi-12 > srfi-19 > tcp regex-case + dot-locking should be straightforward. I'll take care of those. I can look into s11n, as well. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
Hello Matt, > NOTE: Aside from the effort in porting the code there are still a few > dependencies on eggs that have not been ported. Triming dependencies > may eliminate some of these. A quick crude scan of use statements gave > me this: [...] I've ported the hostinfo egg and sent a patch to Jim, haven't heard back from him yet. There should be no need to port ports and tcp as they are units in C4, not eggs. I remember working on the csv or csv-xml egg, but cannot find any evidence towards this. If you need porting help, feel free to let the mailing list know. Vasilij signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
On Sat, 2019-09-28 at 19:18 +0200, Jörg F. Wittenberger wrote: > Am Fri, 27 Sep 2019 23:27:23 +0200 > schrieb felix.winkelm...@bevuta.com: > > > > Hi all, > > > > > > Attached is a relatively straightforward patch for SRFI-13. It > > > changes the let-string-start+end macro (and also > > > let-string-start+end2 but that isn't exported) so that it uses > > > let-optionals* and the entire picking apart of the rest arg list > > > into start/end can be completely inlined, as well as checking the > > > values against the string length(s). > > > > Wonderful! Applied and tagged (0.3). > > Would it make sense to apply this also on Chicken 4? > > I see the latter living for quite a while. > > If nothing else than if it just was for me. :-/ It will be a while before I can migrate away from Chicken 4 so count me among those who would be appreciative of any porting of fixes/improvements from chicken 5 to 4. I'm keen on getting to Chicken 5 as soon as possible but it is a large task and is likely to take six months to a year. NOTE: Aside from the effort in porting the code there are still a few dependencies on eggs that have not been ported. Triming dependencies may eliminate some of these. A quick crude scan of use statements gave me this: call-with-environment-variables csv csv-xml dot-locking foof-loop hostinfo pathname-expand ports regex-case rpc s11n sparse-vectors srfi-12 srfi-19 tcp > > ___ > Chicken-hackers mailing list > Chicken-hackers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
Am Fri, 27 Sep 2019 23:27:23 +0200 schrieb felix.winkelm...@bevuta.com: > > Hi all, > > > > Attached is a relatively straightforward patch for SRFI-13. It > > changes the let-string-start+end macro (and also > > let-string-start+end2 but that isn't exported) so that it uses > > let-optionals* and the entire picking apart of the rest arg list > > into start/end can be completely inlined, as well as checking the > > values against the string length(s). > > Wonderful! Applied and tagged (0.3). Would it make sense to apply this also on Chicken 4? I see the latter living for quite a while. If nothing else than if it just was for me. :-/ ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
> Hi all, > > Attached is a relatively straightforward patch for SRFI-13. It changes > the let-string-start+end macro (and also let-string-start+end2 but that > isn't exported) so that it uses let-optionals* and the entire picking > apart of the rest arg list into start/end can be completely inlined, > as well as checking the values against the string length(s). > Wonderful! Applied and tagged (0.3). felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling
Hi all, Attached is a relatively straightforward patch for SRFI-13. It changes the let-string-start+end macro (and also let-string-start+end2 but that isn't exported) so that it uses let-optionals* and the entire picking apart of the rest arg list into start/end can be completely inlined, as well as checking the values against the string length(s). The old version was written in terms of the awkward string-parse-start+end and string-parse-final-start+end procedures, which could of course not be inlined. The performance benefit seems to be quite a bit: total runtime of the srfi-13 benchmark suite in chicken-benchmarks went from 58s to 36s. Here's the cpu time (right is with patch, left without. Higher numbers are better): === === cpu-time === Programs [1] [2] string-ci-equal___1.00__2.39 string-concatenate1.00__1.00 string-contains___1.00__2.45 string-contains-ci1.00__2.22 string-drop___1.00__1.00 string-drop-right_1.00__1.00 string-equal__1.00__2.37 string-join___1.00__1.00 string-prefix_1.00__1.85 string-prefix-ci__1.00__1.80 string-suffix_1.00__1.83 string-suffix-ci__1.00__1.74 string-take___1.00__1.01 string-take-right_1.00__1.01 NOTE: The moving of the ##sys#check-fixnum calls in string-pad, string-pad-right, string-hash and string-hash-ci are not strictly needed to improve the performance with current CHICKEN, but they are useful for a patch I'm working on which eliminates the need to cons up a rest list for optional arguments. This also applies to the note I added regarding complex expressions. Feel free to remove it. Cheers, Peter Index: srfi-13.scm === --- srfi-13.scm (revision 37885) +++ srfi-13.scm (working copy) @@ -222,35 +222,39 @@ ;;; Support for START/END substring specs ;;; +(define-syntax check-string-lengths + (syntax-rules () +((check-string-lengths s start end) + (let* ((slen (string-length s))) + (cond ((not (and (fixnum? start) (>= start 0))) + (##sys#error 'proc "Illegal substring START spec" start s))) + (cond ((not (and (fixnum? end) (<= end slen))) + (##sys#error 'proc "Illegal substring END spec" end s))) + (unless (<= start end) + (##sys#error 'proc "Illegal substring START/END spec" start end s)) + (define-syntax let-string-start+end2 (syntax-rules () -((_ (s-e1 s-e2 s-e3 s-e4) proc s1 s2 args . body) - (let ((procv proc)) - (let-string-start+end -(s-e1 s-e2 rest) procv s1 args -(let-string-start+end - (s-e3 s-e4) procv s2 rest - . body) ) ) ) ) ) +((let-string-start+end2 (start1 end1 start2 end2) proc s1-exp s2-exp args-exp body ...) + (let ((s1 s1-exp) (s2 s2-exp)) + (let-optionals* args-exp ((start1 0) (end1 (string-length s1)) + (start2 0) (end2 (string-length s2))) + (check-string-lengths s1-exp start1 end1) + (check-string-lengths s2-exp start2 end2) + body ...))) ) ) (define-syntax let-string-start+end - (er-macro-transformer - (lambda (form r c) - (##sys#check-syntax 'let-string-start+end form '(_ _ _ _ _ . _)) - (let ((s-e-r (cadr form)) - (proc (caddr form)) - (s-exp (cadddr form)) - (args-exp (car (cr form))) - (body (cdr (cr form))) - (%receive (r 'receive)) - (%string-parse-start+end (r 'string-parse-start+end)) - (%string-parse-final-start+end (r 'string-parse-final-start+end))) - (if (pair? (cddr s-e-r)) - `(,%receive (,(caddr s-e-r) ,(car s-e-r) ,(cadr s-e-r)) - (,%string-parse-start+end ,proc ,s-exp ,args-exp) - ,@body) - `(,%receive ,s-e-r - (,%string-parse-final-start+end ,proc ,s-exp ,args-exp) - ,@body) ) + (syntax-rules () +((let-string-start+end (start end) proc s-exp args-exp body ...) + (let ((s s-exp)) ; Note: if this is a complex expression, it's less efficient + (let-optionals* args-exp ((start 0) (end (string-length s))) + (check-string-lengths s start end) + body ...))) +((let-string-start+end (start end rest) proc s-exp args-exp body ...) + (let ((s s-exp)) + (let-optionals* args-exp ((start 0) (end (string-length s)) rest) + (check-string-lengths s start end) + body ...) ;;; Returns three values: rest start end @@ -1015,9 +1019,9 @@ ; (exact? bound) ; (<= 0
