Looks like that run had more useful info. Your uses of `string-trim` and `fprintf` are probably worth investigating.
Vincent On Sat, 16 Jan 2016 21:01:22 -0600, Brian Adkins wrote: > > On Saturday, January 16, 2016 at 9:40:51 PM UTC-5, Vincent St-Amour wrote: > > Brian, > > > > The Racket profiler is an edge profiler. So in addition to telling you > > which code time is spent in, it's also telling you which callers caused > > which proportion of that time. > > > > In the case of [48], it's telling you that file output is a significant > > bottleneck, and that it's caused by the code at [2], [38], [39], etc. > > (as well as by recursive calls to `call-with-output-file`). > > > > As for the `for` ([49]), the loops at [40] and [37] are the main > > culprits. > > > > Based on that, you could try redirecting output to `open-output-nowhere` > > if you want to profile your computation (as opposed to output), or you > > could try batching your output (fewer, larger `printf`s instead of many > > small ones) to reduce the cost of output. > > > > Vincent > > Thanks. I used open-output-nowhere and got the following profile info: > > https://gist.githubusercontent.com/lojic/db6e02d0d9d88e1d5ced/raw/1002b6e6ee14f2c59b067abe6eac0488a3f2dc7a/profile.txt > > I was surprised that using open-output-nowhere is actually slower though !! > Runtime was 13,761ms vs. 10,258ms with real I/O. > > I'm going to follow up another thread I started a while back with more > performance info. > > It's definitely a CPU bound app (only able to write about 4 MB/s). Even the C > version (see other thread shortly) is CPU bound, and it's pushing 90+ MB/s to > disk. I have an SSD. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
