[racket] DrRacket sluggishness since upgrading to 5.3.1 (OS X 10.6.8, 64-bit build)

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Sat Nov 17 22:56:10 EST 2012

On Sat, Nov 17, 2012 at 9:47 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:
> On Sat, Nov 17, 2012 at 10:28 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> It sounds like there is a leak somewhere. Does it happen if you are
>> just editing, and not running your program?
> I've been doing both, so I can't really say. As I mentioned, though, I
> had plenty of free memory when this was happening. I'm trying to
> reproduce the problem now without running the program. I might give
> git head a try, too. -J


Try keeping an eye on the GC icon. If the sluggishness is correlated
with it blinking that's a different problem than the one I've been
tackling. If, on the other hand, you see sluggishness when the gc
light isn't turning on, then that's interesting.

I should point out that I didn't speed up tab switching too much. It
is a little bit better now, but it does a lot of work (it can be as
much as 600 msec on my machine with a large window and the contour
open). I also didn't improve the contour window much. I've looked into
it some, but I think I need a different strategy for it's
implementation. I hope to get to that before the next release goes
out, but if you want high interactivity in the meantime, close it.

Another thing to try: click the "gc" icon a few times and see if that
helps. (It may be the case that parts of DrRacket are paged out and
clicking that will likely page them back in.)

I have no idea if this is happening, but I just feel like pointing out
that non-tail infinite loops in your programs can quickly eat up all
your memory (with only 3.5 gigs) and you might not know that since you
have the memory limit turned off. That can make DrRacket's heap get
very large. It will get small again if that memory isn't used, but
large collections will take a long time in the interim.


Posted on the users mailing list.