I like Eric Wastl’s work (so much that I licensed one of his puzzles for 
Beautiful Racket). He often designs them to foil naive algorithms. What other 
languages call a list is often better modeled in Racket as a vector. I did the 
initial 2018 puzzles specifically with the goal of making them fast. In one 
case I switched to mutable pairs; in another, a double linked list (rather than 
the usual, which is single linked) to avoid excessive traversal. In general I 
often try to think of algorithmic problems in terms of physical movement, and 
then how to minimize that movement. 

https://github.com/mbutterick/aoc-racket/tree/master/2018

> On Mar 21, 2019, at 7:24 PM, Joel Dueck <[email protected]> wrote:
> 
> I could have used such a book during the 2018 Advent of Code. I seem to 
> recall I spent a lot of time scrounging for faster ways to do things after 
> the simple, “idiomatic” Racket approach (or rather my novice-level 
> conceptions of those approaches) resulted in extremely slow code. I was more 
> or less successful in most cases[1] but I was never able to match the speeds 
> that the Python users said they were achieving.
> 
> [1]: https://thenotepad.org/repos/aoc2018/
> 
>> On Thursday, March 21, 2019 at 7:10:49 PM UTC-5, Matthew Butterick wrote:
>> As a Racket rule of thumb, I find that most efforts toward "custom-built 
>> loops" end in defeat, because the Racket macro expander and JIT compiler are 
>> aware of better optimizations. If I were writing another book on Racket, it 
>> would be High-Performance Racket, which I know more about than I used to, 
>> but still not very much ;)
>> 
>> 
>>> On Mar 21, 2019, at 12:15 PM, Joel Dueck <[email protected]> wrote:
>>> 
>>> Yes, first-words-regex2 is pretty much identical in performance to my 
>>> longer regex-less version. Thanks for the pointer! I was not familiar with 
>>> the use of regexp-match functions on an input port. It’s a little wild to 
>>> me how even using a string port, a general-purpose pattern matching 
>>> function can be just about as fast as a custom-built loop that knows 
>>> exactly what it wants. But the regex library has probably been pretty well 
>>> optimized by now.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Pollen" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to