Where to start with optimizing Racket programs?

Questions & Answers
21

I will say I use the profiler a lot when optimizing. There are two big challenges when using the profiler:

  1. It doesn't tell you about the internals of runtime operations (which can be cheap like vector-ref or expensive like local-expand).
  2. It can't tell you about costs that are internal to the runtime, like allocation, garbage collection, or chaperone wrappers. Different tools are needed for that.
2 Likes
22

I agree with @samth; the profiler is the first thing I reach for when trying to understand some bad performance. It has limitations but sometimes it just delivers the answer.

2 Likes
23

I understand a bunch of this is likely tacit knowledge, but putting together some non-exhaustive list of such expensive operations in the documentation would be very helpful!

24

On Jan 9, 2024, at 10:15 AM, Greg Hendershott via Racket Discourse notifications@racket.discoursemail.com wrote that “[a]nother factor is the Racket community of tool users and tool improving contributors is some orders of magnitude smaller than say Python.”

That’s precisely it. I reach for the profiler extensively once or twice a year. We just published another paper on the profiler, on using it on a large number of cases (automatically). If someone wants to join Ben and/or Christos in tackling the profiler and improving it, please let them know.

25

Although it's not exactly what you're asking for, there are some tips sprinkled throughout the Performance section of the Guide.

26

I don't think there's anything useful to say about most of those; directory-list is slower than open-input-file is slower than hash-ref is slower than vector-ref for the obvious reasons. The latter two do say something about their complexity.