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.


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.

Reply via email to