search

tony-o / raku-fez

This project is for 'fez', raku's cool new shiny dist uploader & manager. If you're a module author you should definitely be using this sweet thang. ;;;;;;;;;;;;;; This project and the underlying infrastructure is supported out of my own pocket and through donations. If you'd like to donate please check here: https://www.patreon.com/oynot
Artistic License 2.0
20 stars 12 forks source link

Potential Slowness in Ventura with Tar #76

Closed masukomi closed 1 year ago

masukomi commented 1 year ago

This needs community input to confirm it's not just me, what exactly the problem is, and how bad it is

this is an extension of this comment on an tantgentally related issue.

After upgrading to macOS Ventura i'm seeing tar take ~12 minutes in the checkbuild step on an m1 mac that's pretty well specced out.

COMMUNITY PLEASE RUN THE FOLLOWING TESTS:

Setup

  1. zef uninstall fez
  2. download fez from source (this repo)
  3. add die "xxx"; on line 542 (after the block calling checkbuild and before attempting to upload)

Monterrey users

in a repo that has resources run the following (change the path to match whever you downloaded raku-fez)

time raku -I ~/path/to/raku-fez/lib ~/path/to/raku-fez/bin/fez upload

it won't upload because of the die you added.

add "bundlers": ["Fez::Util::Tar"] to your ~/.fez-config.json

run the timed upload command again.

If the time difference is notable please post the output of time. If the time difference is not notable please comment to that fact.

Ventura users

same deal, but different question.

Based on what i found in the other ticket you probably aren't using pax (see below how to test this if you've got a couple extra minutes). You're ONLY running tar so the output times should be the same with our without that change.

The question for you is "is it ridiculously slow"? If yes, let us know if you're on ARM or Intel and add the output from time If no, let us know if you're on ARM or Intel.

Want to do a little extra digging?

in Bundle.rakumod insert a new debug output after the for @chandlers -> $h { block and before the die immediately after it.

your line should say something like note("XXX \@handlers: " ~ @handlers.raku)

we need to know if the Pax handler is in that list or just the Tar handler.

tony-o commented 1 year ago

There was a bug ~2 versions ago that affected tar, what version of fez are you running?

masukomi commented 1 year ago

what version of fez are you running?

the most recent version in this repo, which claims to be 38 in the META6.json but there are no tags or releases here and the latest commit message from e6c08626e4ae5d5ed9762ea08b09e5cdde8256de is "oops" so... who knows what I'm actually looking at.

[edit] just noticed there are newer commits, but the META6 still claims 38 and there are no tags so... i have even less confidence in what i'm actually looking at. Will try again with the newer commits and report back.

tony-o commented 1 year ago

As commented in the other reports, please include environment information as well as the version of fez you're running in these reports. fez -v will show you what version of fez you're running.

A bug on this repo is not an appropriate place to poll users. Please use IRC, twitter, reddit, or discord for polling raku's community.

masukomi commented 1 year ago

A bug on this repo is not an appropriate place to poll users. Please use IRC, twitter, reddit, or discord for polling raku's community.

To be explicit, I wasn't polling users to see if there's a bug. There IS (or at least "was") a bug. I was instructing users on how to test it so that we could have a better understanding of how widespread the bug was and on what environments it presented itself. Having that data in irc wouldn't be useful here for understanding the cause of the problem.

fez -v will show you what version of fez you're running.

fez -v will show you what the META6.json claims is the version you're running. this is not the same thing. There are many commits which will all say 38 but they are not all the same functionality. 39 doesn't exist in this repo even though 39 is the currently distributed version. this makes it really hard to test the current / correct code.

I did note that 38 was what the META6 claimed.

Note that it's impossible to tell if pax is being invoked or not with the distributed version one must be running from source in order to tell which makes the -v data wholly irrelevant.

environment: