On 7/25/2017 12:45 AM, Lehi Toskin wrote:
I have noticed that printing in DrRacket is rather slow and I'm wondering if
that's something I could speed up. If I have a loop that runs and prints a
whole lot of information each loop, were I to become overwhelmed and click the
Stop button, it would take a minute or so before my wishes made it through to
Running the same hypothetical program from the command line, the printing
process is executed much faster and if I Ctrl-C the change is instantaneous.
Am I making any sense?
First thought is that DrRacket may not be as heavily optimized for text
output as is the command line window.
I know that DrRacket was created using Racket's own GUI/drawing
libraries. I am *NOT* an expert on Racket's GUI stuff, but I know from
other experience that fast scrolling of bitmapped text requires
cleverness in the code: keeping track of what is visible vs hidden,
double buffering output, always minimizing what is attempted to be
(re)drawn, and having fast BitBLT functions to use.
Having little experience with Racket's drawing library, I can't speak to
how fast it is. I do recall someone saying it was (mostly) just a thin
layer over the native platform library, but even "thin layers" add some
latency. Nor do I have any clue as to how clever DrRacket is with its
Second ... as I [perhaps mistakenly!] understand it ... DrRacket
executes your program as a custodian thread within the same VM
instance. That means that DrRacket's own functions - console (REPL)
I/O, GUI control, monitoring, logging, GC, etc. - all are competing with
whatever your program is trying to do.
The stock advice has always been: if you want speed, run from the
You received this message because you are subscribed to the Google Groups "Racket
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.