Slow racket startup for a certain setup (testing with rash package)

37 views
Skip to first unread message

Nathaniel W Griswold

unread,
May 19, 2021, 1:15:27 PM5/19/21
to racke...@googlegroups.com
Hello. I configured racket on my system with a custom directory installation package scope and ran into an extremely long (about 20 second) startup time for loading racket and the package rash/repl. didn't have time today to investigate today, but thought i would send along some details just in case someone more experienced with racket might see it or hear my problem and immediately realize the problem. There is no stderr output by the racket process for the slow case, everything just takes longer.

I've attached two logs for the output of the command `strace racket -l rash/repl >/tmp/rash.log 2>&1`

The first (slow, system) log is for my system-wide installation directory scope of racket on my system in "/opt/Racket 8.1/share/pkgs-system/". The slower of the logs is about three times bigger than the other. It contains a lot of spammy repeated syscalls of lseek(3, 0, SEEK_CUR) and clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &t). I don't know if that is significant but it seemed odd.

My user share directory in /home/griswold/.local/share/racket/8.1 did not exist for the first log. A symlink existed from "/opt/Racket" -> "/opt/Racket 8.1".

I don't really know what is going on. Does anyone understand why this might have occured? Maybe i have done something stupid. But i wanted to report it just in case it is a bug.

Attached are the strace logs for the two cases, system directory and user scope.

Thank you

Nate
logs.zip

Nathaniel W Griswold

unread,
May 19, 2021, 1:21:04 PM5/19/21
to racke...@googlegroups.com
Oh, i forgot to mention, more details about what i actually did in this setup are in my racket-users post here: https://groups.google.com/g/racket-users/c/gHS399CXiUE

Nate
> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CC826DC8-5919-47F7-912E-35437DDF7667%40manicmind.earth.
> <logs.zip>

Matthew Flatt

unread,
May 19, 2021, 1:34:16 PM5/19/21
to Nathaniel W Griswold, racke...@googlegroups.com
This kind of problem sounds like ".zo" files are missing or have a
timestamp that is earlier than the corresponding ".rkt" files.

That's why the slow log shows a stat on "rash/repl.rkt", then a stat on
"rash/compiled/repl_rkt.zo", then an open on "rash/repl.rkt".

The fast log shows a stat on "rash/repl.rkt", then a stat on
"rash/compiled/repl_rkt.zo", then an open on
"rash/compiled/repl_rkt.zo".

Using `raco setup rash` should solve the problem (`sudo`ing if
necessary to have write permission).
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to racket-dev+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/CC826DC8-5919-47F7-912E-35437DDF766
> 7%40manicmind.earth.
>
> ------------------------------------------------------------------------------
> [application/zip "logs.zip"] [~/Desktop & open] [~/Temp & open]

Nathaniel W Griswold

unread,
May 20, 2021, 3:22:23 AM5/20/21
to Matthew Flatt, racke...@googlegroups.com
Yes, that was it. `sudo raco setup` built the .zo's, which were missing.

I guess the my question would be why do i have to run that?

Here is the recipe for what i did (on a current debian testing system):

1) curl -OL 'https://mirror.racket-lang.org/installers/8.1/racket-8.1-x86_64-linux-cs.sh'
2) sudo sh racket-8.1-x86_64-linux-cs.sh --in-place --dest "/opt/Racket 8.1"
3) Set "/etc/Racket 8.1/etc/config.rkt" contents to:
---
#hash((build-stamp . "") (catalogs . ("https://download.racket-lang.org/releases/8.1/catalog/" #f)) (doc-search-url . "https://download.racket-lang.org/releases/8.1/doc/local-redirect/index.html") (pkgs-search-dirs . ("/opt/Racket 8.1/share/pkgs-system" #f)) (links-search-files . ("/opt/Racket 8.1/share/pkgs-system/links.rktd" #f)))
---
4) sudo /opt/Racket\ 8.1/bin/raco pkg install --scope-dir "/opt/Racket 8.1/share/pkgs-system" readline-gpl rash
5) /opt/Racket\ 8.1/bin/racket -l rash/repl

The last command takes a long time every time. The docs and zos and bin files are missing. I run `/opt/Racket\ 8.1/bin/raco setup rash`. Now all docs bins zos in place and (5) runs quickly.

Why? I don't think i'm going to use this method anymore, but if i did then should i `raco setup` the other packages (rash deps) too?

Thanks

Nate
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20210519113412.259%40sirmail.smtps.cs.utah.edu.

Nathaniel W Griswold

unread,
May 20, 2021, 5:27:20 AM5/20/21
to Matthew Flatt, racke...@googlegroups.com
Ignore the very last question. I was running `sudo raco setup` for all packages.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/68009F07-06F8-4483-8983-49D6E39CE0E9%40manicmind.earth.

Matthew Flatt

unread,
May 20, 2021, 8:30:45 AM5/20/21
to Nathaniel W Griswold, racke...@googlegroups.com
Thanks for providing the step-by-step instructions!

I see that when `raco pkg install` runs `raco setup` in step 4, it
effectively uses `--avoid-main`, since the scope is not "installation".
To be consistent with `raco setup`, `raco pkg install` should use
`--avoid-main` only when the scope is specifically "user", and I'll fix
that.

Your 'pkgs-search-dirs configuration puts the new scope even before
user scope, so there's a kind of mismatch between the idea that it's a
non-user scope and the package search order. As you note in follow-ups,
the new and improved layering support is more the way to go.

Nathaniel W Griswold

unread,
May 20, 2021, 8:56:17 AM5/20/21
to Matthew Flatt, racke...@googlegroups.com
>
> I see that when `raco pkg install` runs `raco setup` in step 4, it
> effectively uses `--avoid-main`, since the scope is not "installation".
> To be consistent with `raco setup`, `raco pkg install` should use
> `--avoid-main` only when the scope is specifically "user", and I'll fix
> that.

Great, glad i could help.

>
> Your 'pkgs-search-dirs configuration puts the new scope even before
> user scope, so there's a kind of mismatch between the idea that it's a
> non-user scope and the package search order. As you note in follow-ups,
> the new and improved layering support is more the way to go.


Oh, ok. I was just being careless i think. I think what i kinda wanted for 'pkgs-search-dirs was `(#f "/opt/Racket 8.1/share/pkgs-system")` and not `("/opt/Racket 8.1/share/pkgs-system" #f)`. I guess that would be priority ordered {user, distribution, new-opt-system-scope}. That's kinda not what i wanted either, though. I think what i really wanted is {user, new-opt-system-scope, distribution}.

That's what most would be going for right? If so, is there a current good way to do that ordering? Does the new stuff do it that way?

Nate

Matthew Flatt

unread,
May 20, 2021, 9:15:38 AM5/20/21
to Nathaniel W Griswold, racke...@googlegroups.com
At Thu, 20 May 2021 07:56:15 -0500, Nathaniel W Griswold wrote:
> > Your 'pkgs-search-dirs configuration puts the new scope even before
> > user scope, so there's a kind of mismatch between the idea that it's a
> > non-user scope and the package search order. As you note in follow-ups,
> > the new and improved layering support is more the way to go.
>
>
> Oh, ok. I was just being careless i think. I think what i kinda wanted for
> 'pkgs-search-dirs was `(#f "/opt/Racket 8.1/share/pkgs-system")` and not
> `("/opt/Racket 8.1/share/pkgs-system" #f)`. I guess that would be priority
> ordered {user, distribution, new-opt-system-scope}. That's kinda not what i
> wanted either, though. I think what i really wanted is {user,
> new-opt-system-scope, distribution}.
>
> That's what most would be going for right? If so, is there a current good way
> to do that ordering? Does the new stuff do it that way?

It looks like I was mistaken: The #f in a search list is replaced only
with the main directory, and the user directory is always put on the
front --- which is good, because that works better in general (but I
think some of the documentation is wrong, now).

So, the configuration is what you intended, after all.


Matthew
Reply all
Reply to author
Forward
0 new messages