> On Jun 1, 2017, at 10:52 AM, Steve Byan's Lists <steve-l...@byan-roper.org> > wrote: > > Hi Jon, > >>> On May 31, 2017, at 6:41 PM, Steve Byan's Lists <steve-l...@byan-roper.org> >>> wrote: >>> >>> On May 31, 2017, at 6:14 PM, Jon Zeppieri <zeppi...@gmail.com> wrote: >>> >>> So, for example: >>> >>> (define (map-trace stat%-set in-port) >>> (for/fold ([sexp-count 0]) >>> ([trace-record (in-port read in)]) >>> (+ sexp-count 1))) >>> >>> (I didn't try this, but I think it's right.) >>> >>> This way, you don't build up a list or a lazy stream; you just process >>> each datum as it's read. >> >> Thanks, I don't recall why I didn't think of this alternative. I guess I was >> hung up on streams, or else not thinking of s-expressions as lists :-( > > Alas, it's only a 13% reduction in run-time. About 91K records/second as > opposed to 80K records/second. (I'm running on a system with turbo-boost > enabled today, hence the 80K recs/sec for the stream instead of the 62K I > reported yesterday.) > > I'll make another try using Neil's approach of formatting the trace records > as a simple list. >
If you try the simple list approach, consider using vectors instead of lists. The memory representation is flat, so it should be a bit more efficient, and it's every bit as easy to use match with vectors. (Prefab structs are another possibility.) However, you might just find that nothing will make this general approach fast enough. By the way, match tends to generate good code, so I wouldn't be too worried about its overhead, unless you're doing something like matching list elements out-of-order. > Best regards > -Steve > > -- > Steve Byan > steveb...@me.com > Littleton, MA > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
