Open jpolitz opened 11 years ago
Given how old this is, I'm wondering if it's still a relevant issue?
The body text of the issue isn't very relevant, but the spirit is, actually. It still takes a while for the CLI to load up, and "initial imports" is still a pretty good description of what takes time.
Standalone files with only the bare-bones dependencies are better, but still in the quarter-second range.
Still?
The CLI server implementation mitigates this to some extent.
I've edited the issue title to reflect a real goal. If Pyret loaded within 100-200ms for lists, option, error, etc, then this wouldn't be a user-visible delay. If things like error could be lazily loaded when needed, that might help. If files were smaller or better tree-shaken, that would help. But it still takes about 0.75 seconds to run the compiled standalone for "hello world" at the command line, which is not great.
Here's a quick measurement of load times in nanoseconds using process.hrtime in node (so, e.g. error.arr takes 150 ms, lists and sets take 50ms, checker takes 60ms, etc)
builtin://global : 000716491
builtin://option : 002629133
builtin://either : 000901201
builtin://error-display : 023990422
builtin://valueskeleton : 002065896
builtin://srcloc : 004966697
builtin://error : 156337802
builtin://equality : 002321185
builtin://lists : 058493214
builtin://arrays : 013585211
builtin://pick : 001626679
builtin://sets : 050532366
builtin://contracts : 028785125
builtin://string-dict : 006217741
builtin://render-error-display : 008343032
builtin://ffi : 001697921
builtin://checker : 068642305
builtin://table : 001695929
builtin://tables : 019320626
builtin://reactor-events : 001790925
builtin://reactors : 001224176
builtin://data-source : 027683542
builtin://s-exp-structs : 001451026
builtin://s-exp : 000670692
builtin://base : 000312295
Note that this accounts for about 350 ms if you add it up. Parsing and loading all the code to get this started takes another ~350ms.
@jpolitz just curious where we stand on these numbers. CPO has made huge strides in load time since then.
These programs are slow and they shouldn't be (this is after raco make):
$ time racket src/lang/tokenizer.rkt
real 0m0.272s user 0m0.236s sys 0m0.032s
$ time racket src/lang/grammar.rkt
real 0m0.221s user 0m0.184s sys 0m0.028s
$ time racket src/lang/desugar.rkt
real 0m0.442s user 0m0.392s sys 0m0.048s