On Sat, Mar 2, 2019 at 3:38 PM Matthew Flatt <mfl...@cs.utah.edu> wrote:

>
> That's a big difference between Racket and Racket CS. My initial
> thought was that the program must have a lot of indirect function
> calls, and Racket CS is faster at those... but not by such a big
> factor. You don't use `call/cc`, right?
>

No call/cc. These are just normal functions that get tail-called by the
parsers.

There definitely are a lot of indirect function calls. I've tried using
`define-inline` in a bunch of places to mitigate the effect. Doesn't seem
to help.


>
> A difference of 60ms/140ms versus 3.3s sounds algorithmic, as opposed
> to something about the representation or cost of functions as
> continuations.
>
> How much memory does the program use, and how much of the run time is
> GC time?
>

How would you measure the former? Use a larger file and monitor the
process? Or is there a better way within racket? Start a thread that dumps
current-memory-use every so often?

GC accounts for a bit less than a tenth of the total time, which seems to
be on par with the parser in the json module.

I also just realized that I wasn't using profile with errortrace, even
though I thought I was. I do get much more information with errortrace on.
It does seem to confirm the hypothesis that a lot of time is spent in
unknown function calls. (Though I also wonder of errortrace is prohibiting
any inlining, which would turn many unknown calls into known ones.) Also, a
good amount of time is spent looping (`for` loops using `in-bytes`, but a
#:when that uses an unknown predicate).

- Jon

-- 
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.

Reply via email to