Racket 6.4 very slow

[vkelm...@aol.com]

I recently downloaded Racket version 6.4. I have previously been using version 6.1. It is much slower than version 6.1. Several short functions run approx 20 times slower on 6.4 than 6.1. These were run at the same time on the sam matine in succession.
I am using Mac osX version 10.8.5
Has anyone else noticed this?

[Matthias Felleisen]

Something is wrong with your installation. 6.4 is in the same ball park as 6.1 Can you share the code that runs 20x slower? Thanks — Matthias

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[vkelm...@aol.com]

[vkelm...@aol.com]

On Tuesday, March 1, 2016 at 10:51:58 PM UTC-5, vkelm...@aol.com wrote:

(define (total n)
(for/sum ([x (in-range (+ 1 n))]) x))
(time (total 1000000000))
in Racket 6.1 just now 5287 milliseconds. In Racket 6.4 102384 milliseconds.
Also: When I am typing in the interactions pane of 6.4 there is often a 1-2 second delay before my
keystrokes show up.

[Matthias Felleisen]

It sounds like your files are not compiled. Try

raco setup

in a shell. You may need to supply some command line flags if your files are half way compiled.

(Your examples runs in 3200 ms on my Mac in Racket 6.4.1)

[Stephen Chang]

In general, times reported in DrRacket are unreliable.

See: https://docs.racket-lang.org/guide/performance.html#%28part._.Dr.Racket-perf%29

Try the command line. Here's what I get on my machine:

$ ~/racket61/bin/racket
Welcome to Racket v6.1.
-> (define (total n)

(for/sum ([x (in-range (+ 1 n))]) x))

-> (time (total 1000000000))
cpu time: 3044 real time: 3051 gc time: 0
500000000500000000

$ ~/racket62/bin/racket
Welcome to Racket v6.2.
-> (define (total n)

(for/sum ([x (in-range (+ 1 n))]) x))

-> (time (total 1000000000))
cpu time: 3036 real time: 3046 gc time: 0
500000000500000000

$ ~/racket63/bin/racket
Welcome to Racket v6.3.
-> (define (total n)

(for/sum ([x (in-range (+ 1 n))]) x))

-> (time (total 1000000000))
cpu time: 3040 real time: 3045 gc time: 0
500000000500000000

$ ~/racket64/bin/racket
Welcome to Racket v6.4.
-> (define (total n)

(for/sum ([x (in-range (+ 1 n))]) x))

-> (time (total 1000000000))
cpu time: 3036 real time: 3041 gc time: 0
500000000500000000

[Jens Axel Søgaard]

2016-03-02 19:26 GMT+01:00 vkelmenson via Racket Users <racket...@googlegroups.com>:

 

Also: When I am typing in the interactions pane of 6.4 there is often a 1-2 second delay before my
keystrokes show up.

It sounds as if something went wrong during the installation on Racket.

How did you install it?

If you compiled it yourself, you most likely forgot to run raco setup.

The downloads from download.racket-lang.org contains precompiled files.

/Jens Axel

 

[vkelm...@aol.com]

On Tuesday, March 1, 2016 at 10:51:58 PM UTC-5, vkelm...@aol.com wrote:

Obviously something is wrong with my setup. I uninstalled version 6.4 from my computer and reinstalled the dmg from the download site. It is still the same. I am not going to have access to my desktop for about 10 days. I will see what happens with a laptop.

[Neil Van Dyke]

If your Racket install is good... You might have instrumentation-heavy
settings in DrRacket, and/or the compilation of your files is somehow
corrupted. Or maybe the cause is with your computer.

Try running your program from the command line, and after deleting your
"compiled" directories for your code and re-compiling your code. And
make sure that some non-Racket issue with your computer isn't slowing it
down (check expensive running processes for CPU/RAM/I/O contention,
check system logs for hardware errors, check that CPU is not scaling for
battery-saving, etc.).

Neil V.

[Jens Axel Søgaard]

Could it be that the OS X 10.8.5 has something to do with it?

Does anybody else have an 10.8 (Mountain Lion) installation?

/Jens Axel

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Jens Axel Søgaard

[Alex Harsanyi]

I have the same problem with Racket 6.4 64Bit Windows (running on Windows 7):

> (time (total 1000000000))
cpu time: 85520 real time: 88070 gc time: 204

BTW, my "Choose Language" dialog box (Ctrl+L) has the following selected:

* Debugging
* Populate "compiled directories"
* Preserve stack trace
* Enforce constant definitions

When disabling the "Debugging", the time goes down significantly:

> (time (total 1000000000))
cpu time: 4555 real time: 5036 gc time: 63

If I also disable the "Preserve stack trace option", the time goes down a bit more:

> (time (total 1000000000))
cpu time: 3619 real time: 3662 gc time: 31

I did not expect the debugging option to have such a huge impact. I don't even know what it does, as there is a separate "Debug" button in the toolbar, which seems to work even when the option is disabled.

BTW, I ran raco setup as suggested in a previous message and after that, DrRacket would not start up anymore [1] and I had to do a fresh install. Racket was installed from the default installer package from racket-lang.org. No additional packages added and the installation was not modified in any way.

Best Regards,
Alex.

[1] https://drive.google.com/file/d/0B5h4XOdkim72bm04eDBGNWpFZ0E/view?usp=sharing

[Matthias Felleisen]

1. Don’t ever measure anything in drracket (version 6.4.1 or earlier).

2. Are you comparing two different installations of Racket like the OP does? Or are you just saying something is slow sometimes?

[Alex Harsanyi]

On Thursday, March 3, 2016 at 11:06:56 AM UTC+8, Matthias Felleisen wrote:

> 1. Don’t ever measure anything in drracket (version 6.4.1 or earlier).

Perhaps this explains why you could not reproduce the problem :-)

DrRacket is the tool most people use to write Racket programs, and I suspect a lot of the time the only place where they run their programs. Most people will judge the speed of Racket by how fast programs run inside DrRacket.

Also, the OP was not talking about shaving a few milliseconds, or even a 2x slowdown, the time difference is huge (20x). This slowdown is not expected by anyone who has some familiarity with other programming environments. If it cannot be improved, perhaps a warning message should be printed in the eval window...

> 2. Are you comparing two different installations of Racket like the OP does? Or are you just saying something is slow sometimes?

My timings are from the same racket installation, Racket 6.4 64 bit Windows 7, default install. Just to recap, for the same code example as the OP presented, running in DrRacket:

* "Debug" and "Preserve stack trace" enabled -> 85 seconds
* "Debug" disabled, "Preserve stack trace" enabled -> 4.5 seconds
* "Debug" and "Preserve stack trace" disabled -> 3.6 seconds.

[Matthew Flatt]

I see that there's a big difference in the effect of debugging mode for
this example in v6.3-v6.4 compared to earlier versions.

On my machine:

Racket DrRacket
with debugging
v6.2 ~2500 ms ~3800 ms
v6.4 ~2500 ms ~63000 ms

In both versions, debugging instrumentation is applied at the
granularity of terms that have source locations. The idea was that
having a source location is a good indication that the code is
something the user wrote, and not in a library.

Starting with v6.3, however, compiled bytecode preserves source
locations for syntax literals --- so, code in a macro implementation
has a source location when it appears in an expansion. With v6.3 and
later, debugging instrumentation is added at many more program points
in the expansion of the `for` macro.

Instead of using the existence of a source location to determine where
to add instrumentation, debugging should be based on the details of the
source location. I'm not immediately sure of the right rule, but I'll
work on it.

Another direction is to improve the overhead of the debugging
instumentation, even when it is applied at a fine granularity. I'm not
clear on why it's so expensive in this case, and I think it should be
easy to improve (but I might be wrong about that).

[Neil Van Dyke]

Alex Harsanyi wrote on 03/02/2016 11:19 PM:
> If it cannot be improved, perhaps a warning message should be printed
> in the eval window...

I like this idea. Maybe add to the DrRacket REPL banner, the
debugging/instrumentation options that are enabled.

> Welcome to DrRacket, version 6.4 [3m].
> Language: racket; memory limit: 128 MB.
> >

Neil V.

[Vincent St-Amour]

On Wed, 02 Mar 2016 22:23:29 -0600,
Matthew Flatt wrote:
> Instead of using the existence of a source location to determine where
> to add instrumentation, debugging should be based on the details of the
> source location. I'm not immediately sure of the right rule, but I'll
> work on it.

Would `syntax-original?` help here?

Vincent

[Matthew Flatt]

Here's a recap of a few points, now that I've spent some time
investigating the issue.


Replicating the problem and detecting debugging mode:

If you start DrRacket fresh or create a new tab and paste

(define (total n)
(for/sum ([x (in-range (+ 1 n))]) x))
(time (total 1000000000))

into the interactions window, then it runs at non-debugging speed.
After clicking "Run" (with an empty program), the interactions window
runs the example with debugging speed.

That difference seems confusing, and it might explain why some had
trouble seeing the example run slowly.

In any case, I agree with the suggest that making DrRacket more clearly
display its current mode could be helpful.


Performance with debugging enabled:

I've made some compiler improvements that cut the debugging-mode time
for the example in half.

I don't think a factor of 10 is completely out of line for a program
that counts up to a billion and adds a pair of small numbers along the
way. Those are such small and optimizable steps that demanding extra
transparency is bound to get in the way. More typical/useful programs
see a smaller cost, because they use larger primitives and spend more
time in libraries.

Even for traditional Scheme benchmarks --- which are written using
minimal bits of the language so that there's little opportunity to hide
behind macro expansions or libraries --- most programs run in debug
mode with slowing factors in the x1.5 to x4 range. That seems
consistent with my experience running unoptimized C for debugging.


Improving the way debugging instrumentation works:

Since the example uses `for/sum`, it should benefit from spending its
time in a library abstraction that is not in debugging mode, as it did
in v6.2 and earlier.

I have an idea for restoring v6.2-like debugging, and I've replied to
Vincent's `syntax-original?` question on the dev list. (Everyone is
welcome to participate there, of course).

[Robby Findler]

On Sat, Mar 5, 2016 at 8:09 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> If you start DrRacket fresh or create a new tab and paste
>
> (define (total n)
> (for/sum ([x (in-range (+ 1 n))]) x))
> (time (total 1000000000))
>
> into the interactions window, then it runs at non-debugging speed.
> After clicking "Run" (with an empty program), the interactions window
> runs the example with debugging speed.
>
> That difference seems confusing, and it might explain why some had
> trouble seeing the example run slowly.

I think this is a bug in the behavior of DrRacket, separate from any
lack of transparency. I've made an attempt at a fix and pushed it.

On Wed, Mar 2, 2016 at 10:25 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:
> Alex Harsanyi wrote on 03/02/2016 11:19 PM:
>>
>> If it cannot be improved, perhaps a warning message should be printed in
>> the eval window...
>
> I like this idea. Maybe add to the DrRacket REPL banner, the
> debugging/instrumentation options that are enabled.

I've pushed something that uses these strings, put onto the name of
the language as shown in the REPL. Is that what you had in mind? Does
it seem helpful?

(module-language-repl-no-annotations "")
(module-language-repl-debug-annotations ", with debugging")
(module-language-repl-debug/profile-annotations ", with debugging
and profiling")
(module-language-repl-test-annotations ", with test coverage")

Robby

[vkelm...@aol.com]

Thanks everyone for your interest and suggestions. I have been away from a computer for a while. The problem is as Matthias says the debugging. In DrRacket 6.4 debugging is on by default. In my installation of 6.1 it is off by default. With debugging off on version 6.4 the difference between the 2 installations on the same computer is approx. 1/10 of a second. Victor Kelmenson