On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson <jjsim...@gmail.com> wrote: > > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: >> >> Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto for >> `y` eliminates the overhead of contracts and brings about another 4x speedup >> on my machine. > > > This is because the compiler is able to remove the contract checks, not > because number->string doesn't have a contract, correct? If it is the > compiler, is there any rule of thumb to determine when the compiler will > likely remove the contract checks? Using typed 'for' iterators seems to be > one case that the compiler optimizes, but can we rely on others?
There are two possible meanings for "contract checks" here. One is "does it check that it gets the right kind of arguments, and raise an error if not". In that sense, every function that is not "unsafe" has contracts, certainly including `number->string`. The other meaning is "uses the `racket/contract` library". The `~r` function has a contract in that sense, while `number->string` does not, and that's a significant source of overhead. On my laptop, just removing the contract on `~r` in the source of the `racket/format` library speeds up Bogdan's revised program from 600ms to 200ms. Most of the time, the compiler does not remove either kind of contract check. Sometimes the first kind of contract check can be removed in the simplest of cases; the second kind is basically never removed by the compiler. There are other cases where macros can generate code that omits contract checks, as with the `for` forms when used with sequence generators like `in-list`, but that is again for simple checks. Sam -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BZHoN--2uJRVeT%2BMHEtbgcDHWtNMYSD45MKNuutwutrUA%40mail.gmail.com.
