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
the program.
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
drawing.
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
command line.
George
--
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.
