Reading image snips takes on the order of seconds for non-trivial images, which is very noticeable for more than a few snips. The bottleneck appears to be in editor-stream-in%’s get-unterminated-bytes. Before I poke around in there, does anyone have some experience to inform attempts to speed that up: approaches that wouldn’t be accepted into the distro (e.g. sacrificing human-readable line lengths in the wxme format?) are okay.

What is the #% for in the following code snippet #:datum-literals (#%negate abs) It’s from a define-syntax-class

@plotnus short answer: it’s just part of the name #%negate, just as -, ?, %, / are parts of names like is-a?, object%, and for/fold. Longer answer is about when people tend to name things with #% at the front, and the short answer to that is for “core” or “meta” forms.

@gfb so pasting an image in DrRacket and saving it, and then reopening it is very slow?

yes

With a fresh install after moving aside the preference file, it doesn’t seem as bad, although I don’t see why doing that would matter. Turning off background expansion might be helping while editing files with images. Where there’s a serious enough delay is when using 2htdp/image produces mrlib/image-core snips, which appear to be an order of magnitude larger than the original (non-racket) image file. When profiling DrRacket those snips didn’t seem to be the main problem, because more time was spent reading, but it turns out that for those snips there’s more to read.