brownplt / pyret-lang

The Pyret language.
Other
1.06k stars 106 forks source link

Pyret's initial imports take more than 100ms #5

Open jpolitz opened 11 years ago

jpolitz commented 11 years ago

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

schanzer commented 8 years ago

Given how old this is, I'm wondering if it's still a relevant issue?

jpolitz commented 8 years ago

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.

schanzer commented 6 years ago

Still?

jpolitz commented 6 years ago

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.

jpolitz commented 6 years ago

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.

schanzer commented 4 years ago

@jpolitz just curious where we stand on these numbers. CPO has made huge strides in load time since then.