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

[Jon Zeppieri]

Since I installed 5.3.1 -- I'm currently on 5.3.1.5 -- DrRacket gets
slower with use. It's snappy enough when first started, but after a
while, it gets sluggish. Switching tabs (and I have only three open)
takes two to three seconds, and scrolling pauses frequently. The
garbage collector seems to be getting quite a workout. (I'm not using
a memory limit, and my machine has about 3.5GB of RAM free.) Disabling
online compilation doesn't fix the problem.

I just noticed that scrolling a buffer brings DrRacket's CPU usage up
to 100%. I don't know if that's common or not; I've never checked
before.

I saw Robby's post on the PLT blog
[http://blog.racket-lang.org/2012/11/drracket-now-more-responsive_15.html].
Are the changes described there in 5.3.1.5?

-Jon
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Robby Findler]

Some of the changes are, but I'm not sure exactly when the version
number bump happened wrt to the changes I've committed.

I don't think I fixed anything having those symptoms, tho.

It sounds like there is a leak somewhere. Does it happen if you are
just editing, and not running your program?

Robby

[Jon Zeppieri]

On Sat, Nov 17, 2012 at 10:28 PM, Robby Findler
<ro...@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

[Robby Findler]

On Sat, Nov 17, 2012 at 9:47 PM, Jon Zeppieri <zepp...@gmail.com> wrote:
> On Sat, Nov 17, 2012 at 10:28 PM, Robby Findler
> <ro...@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

Thanks!

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.

Robby

[Jon Zeppieri]

On Sat, Nov 17, 2012 at 10:56 PM, Robby Findler
<ro...@eecs.northwestern.edu> wrote:
>
>
> 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.
>

Which is the contour window?

> 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.)

Will do. Thanks.

>
> 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.

No, I mean that I had that much ram free *while* the sluggishness was
happening. I had top open in another window. I was definitely not out
of memory.

-Jon

[Robby Findler]

On Sat, Nov 17, 2012 at 10:01 PM, Jon Zeppieri <zepp...@gmail.com> wrote:
> On Sat, Nov 17, 2012 at 10:56 PM, Robby Findler
> <ro...@eecs.northwestern.edu> wrote:
>>
>>
>> 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.
>>
>
> Which is the contour window?

The one you get when you do <menukey>-u; it is a vertical thing along
the right-hand side of the window.

Robby

[John Clements]

I think it's worth mentioning that having a large heap can slow down DrRacket, even if you have lots of free memory. For instance, racket instances using only 100MB are a lot snappier than those using 1.1 GB; I'm not the authority on this, but I think I'm right when I say that sooner or later, you're bound to experience a full collection, and it's just going to take a lot longer when your heap is large.

Apologies if this was all already obvious.

John