I think we must be talking past each other. Let me try to back out a bit. It is my understanding that the trie library's slowness that John reported is all about contract overhead. Specifically, there are some (effectively) lazy contracts on the trie structs that pile up, leading to surprisingly bad performance and that these contracts are generated by TR.
Our initial round of discussion came to the conclusion there's no simple fix to TR or the contract system that can avoid this overhead. So, instead of adding a big warning to the trie library (that Asumu rightly is not excited about :), we could use TR's unsafe require support to implement a small wrapper file that does a more efficient version of the contract checking and then John's problem would be fixed. Over the period between the current and next release we could, in addition, improve TR and the contract system to the point where that wrapper file isn't necessary. That seems good too. It also seems useful to have the short-term fix as part of doing the longer-term fix because that will help us be sure we've really gotten the right contracts in there by comparing the performance of the two versions. Does this make sense as the right way to proceed? Robby On Fri, Jan 8, 2016 at 8:49 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > My suggestion did involve changing TR. I think your suggestion was to > change the trie library, which doesn't have to worry about the Racket > release schedule. > > Sam > > On Fri, Jan 8, 2016 at 9:48 AM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: >> I thought your suggestion involved a change to TR. >> >> But whatever. Do what you want. >> >> Robby >> >> On Fri, Jan 8, 2016 at 8:45 AM, Sam Tobin-Hochstadt >> <sa...@cs.indiana.edu> wrote: >>> This library isn't part of the Racket distribution, so the release schedule >>> doesn't really matter here. >>> >>> Sam >>> >>> On Fri, Jan 8, 2016 at 9:42 AM Robby Findler <ro...@eecs.northwestern.edu> >>> wrote: >>>> >>>> We can do the simpler thing for this release, tho. And changing TR >>>> won't happen for months. The simple suggestion is an easy, immediate >>>> fix, and it will also give us goalposts to shoot for. >>>> >>>> Robby >>>> >>>> On Fri, Jan 8, 2016 at 8:19 AM, Sam Tobin-Hochstadt >>>> <sa...@cs.indiana.edu> wrote: >>>> > I think a better solution is just to add immutable hash tables to TR, >>>> > and then use them in the trie modules. That would allow TR to generate >>>> > exactly the contracts that we could write by hand. >>>> > >>>> > Sam >>>> > >>>> > On Fri, Jan 8, 2016 at 9:06 AM, Robby Findler >>>> > <ro...@eecs.northwestern.edu> wrote: >>>> >> We know there is a much more efficient set of contracts than what TR >>>> >> generates right? How about an unsafe export of TR functions to a >>>> >> wrapper >>>> >> module that implements the safe checks by hand (by macro?)? Maybe that >>>> >> exercise will even feed back into an improvement to TR? >>>> >> >>>> >> Robby >>>> >> >>>> >> >>>> >> On Tuesday, January 5, 2016, Asumu Takikawa <as...@ccs.neu.edu> wrote: >>>> >>> >>>> >>> On 2016-01-05 14:39:17 -0500, 'John Clements' via Racket Users wrote: >>>> >>> > Asumu, does this make sense to you? Note that in particular, I think >>>> >>> > that a >>>> >>> > warning at the top of the pfds package wouldn’t have helped me; I >>>> >>> > think >>>> >>> > a >>>> >>> > warning at the top of each pfds page would make a lot more sense. >>>> >>> >>>> >>> I'd be happy to take a pull request for this. Though I'd also prefer >>>> >>> that >>>> >>> the >>>> >>> library just worked well. >>>> >>> >>>> >>> The pfds could library could also just export everything without >>>> >>> contracts >>>> >>> unsafely. Alternatively we could set it up to generate untyped >>>> >>> variants of >>>> >>> each (with a different module path) that don't optimize or use >>>> >>> contracts. >>>> >>> >>>> >>> Cheers, >>>> >>> Asumu >>>> >>> >>>> >>> -- >>>> >>> 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. >>>> >> >>>> >> -- >>>> >> 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. >>>> >>>> -- >>>> 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. >> >> -- >> 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. -- 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.
