I'm delighted to offer both. Here's a particularly pathological test case:
https://github.com/michaelballantyne/typed-racket-performance
Using a typed/racket/no-check variant of the tr-pfds package makes my
untyped code run 1275x faster. The feature-profile tool reports that
in the TR variant
Your preferences are my command. :)
Actual Performance Bottlenecks (and Workarounds)
(1) Plot's sending of `snip%` instances from untyped to typed code made
them so slow that they were unresponsive. I got around it by making
helper functions to create the snips, and inserting
To offer another speculative solution, perhaps there could be a variant of
Typed Racket structs that are opaque to untyped Racket. If only Typed Racket
code is capable of constructing these objects, the types of their contents
needn't be checked as they pass between typed and untyped code.
On
Submit a bug report, because that number is obviously false. (Or you've
misunderstood how to use it, in which case the documentation probably
needs work. :D)
The problem is that first-order polymorphic contracts are O(n) in the
size of the data. See my other, much, much longer reply to
What I'd much prefer at the moment over speculative solutions are reports of
actual performance bottlenecks. -- Matthias
On May 1, 2015, at 1:09 AM, michael.ballantyne wrote:
I've started using Typed Racket several times recently only to flip the
switch to #lang typed/racket/no-check or
I've started using Typed Racket several times recently only to flip the switch
to #lang typed/racket/no-check or remove types entirely. Something like Vincent
suggests with an option to write with types and have them checked but turn off
the type-driven optimizer and skip contract checking at
6 matches
Mail list logo
