> 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: >>> >>> >>> 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.
Using a simple list gives a 65% reduction in run-time for just reading in the list with the reader. About 256K records/sec. But it's still one and one-half orders of magnitude slower than sucking in the binary, and I'd have to do a fair amount of revision to the Racket code, as well as revising the C++ code that generates the text form of the trace records. And then I'd have to recode the Racket analysis classes to be imperative to try to speed _them_ up. I might be able to get the Racket performance to an acceptable range, but I need to move on to actually using the tool, and I'm more confident that I'll get usable performance recoding it in C++ than by revising the Racket prototype.Thanks for everyone's help, I've learned a lot. 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.
