🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
Xliff \o 06:10
tellable6 2022-09-04T11:31:05Z #raku-dev <lizmat> Xliff: wow, that's.... unexpected
2022-09-04T11:32:08Z #raku-dev <lizmat> Xliff: oddly enough, I don't see any slow down in core compilation
2022-09-04T12:00:51Z #raku-dev <lizmat> Xliff: could you golf a piece of code that compiles noticeably slower: I cannot reproduce what you see locally :-(
Xliff lizmat: Sorry. All I can pass along are my weekly compilation logs that I aborted, yesterday. 06:11
lizmat: Can you confirm stage parse time on your end? What time are you seeing? 06:12
lizmat no change 06:48
30 sec for stage parse of 6.c core 06:49
on my M1 mini
Xliff OK, I am getting 71 seconds. Last week it was 35 and fine. 07:17
So maybe I need to *sigh* nuke my moar blead.
Might be something environmental since I've recently had lots of system instability. 07:18
Another compile takes 70.511 07:20
So another 71.133 seconds after a nuke 07:25
And this is moar-blead
lizmat: Have often do you compile from git?
lizmat well... if I'm working on core stuff, several times a day 07:47
lately I've been focusing more on App::Rak...
lizmat core build time on my Intel mac also are normal 08:26
Xliff lizmat: Thanks. So it's more than likely environmental. 08:33
Wheee.
lizmat Xliff: *or* your code is using some feature that tickles something that slows things down
you are sure it is caused by the commit you mentioned ? 08:34
Xliff I don't think I mentioned a specific commit.
'And this is rakudo.
When CORE.c compile time comes in at over 40 seconds, I worry.
It generally hovers between 29 and 39 seconds.
And while I'm not actually documenting Raku compiles (and perhaps I should) I have been doing these weekly compiles for almost 2 years. 08:35
new-disp growing pains not withstanding. :) 08:36
So if there was a regression, it was done within the last week. Previous weeks compile times ran fine.
Not doing them this week because of the visible regression.
p6-GLib usually hovers in at around 345 seconds. Yesterday it took over 700! 08:37
Fortunately, I can still focus on $dayJob, which I have turned into a Raku-leaning position.
lizmat Xliff++ 08:41
Xliff: do you happen to use a lot of generics in your code ?
vrurg ^^ 08:42
Xliff lizmat: A moderate bit, yes. However not so much for my work in $dayJob, which has also been slightly affected. 08:50
nine You sure you're running an optimized build of MoarVM? 09:08
Xliff nine: Yes. Again, I've been running these compiles for over 2 years. 09:39
So the process is unchanging from week to week
So I now have to assume it is due to recent problems with the environment itself. Those are harder to debug.
Geth nqp: c25f65458b | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for latest fixes
 09:52
Geth rakudo: 7342d9dc28 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM fixes
 10:13
lizmat notable6: weekly 12:50
notable6 lizmat, No notes for “weekly”
vrurg I'm a little bit lost about Xliff issues. Are they about compiling Rakudo? Or compiling gtk? 13:15
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/09/05/2022-...-in-at-50/ 13:25
vrurg: Xliff is seeing up to 2x slower compilation times in their code, /me does not see that in core compilation 13:26
however, it appears Xliff's code is using some generics, and since you worked on that recently, I thought I'd ping you on this 13:27
sena_kun lizmat++ 13:29
vrurg There is possible slowdown on run-time when generics are used, but that's because generics as such are nearly run-time only feature. But there is no chance it could affect Rakudo core compile times. 13:31
lizmat well, It *isn't* about core compile times, but Xliff library compile times 13:32
vrurg Neither compilation of modules should be affected because that would mean the core is using a lot of generics which is not true.
lizmat well... something changed in the past week... :-) 13:33
vrurg The only way to find out is to bisect. 13:34
lizmat yeah :-)
Unfortunately, Xliff is the only one with code to bisect 13:35
vrurg I just've refreshed my memory. The slowdown is possible due to the need to instantiate a generic if used as return type. And dispatching over a generic needs one extra guard over routine's return type because it is not something static per-signature. 13:41
But I don't see how this could cause 2x slowdown on compile times. BEGIN with lots of generics? Even then... 13:42
|Tux| Rakudo v2022.07-35-g7342d9dc2 (v6.d) on MoarVM 2022.07-9-g740f3bcbe
csv-ip5xs0.795 - 0.811
csv-ip5xs-205.094 - 5.330
csv-parser3.476 - 3.800
csv-test-xs-200.406 - 0.407
test6.222 - 6.403
test-t1.380 - 1.407
test-t --race0.826 - 0.827
test-t-2020.868 - 21.982
test-t-20 --race6.369 - 6.511
 14:28

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!